MeteorJS 1.1 is released and I'm pretty excited. Meteor has been a ton of fun for prototypes and weekend projects, so I'm psyched to see this framework get closer to mainstream adoption.
Although I don't do much Windows development these days, official Windows distribution and Mongo DB 3.0 support suggest that Meteor is gaining traction.
What's next on my wishlist? I'd love to see support for PostgreSQL, or any open-source relational database that's production-capable. With strong RDBMS integration, I could probably use Meteor.js on more client projects.
Tuesday, March 31, 2015
Monday, February 23, 2015
In Defense of 80-Character Lines
Given the proliferation of big laptop screens and the current rise of 4K monitors, it's hard to imagine why the old programming practice of "80 characters per line" (80 CPL) would still apply. We have all the screen real estate we need, right, so why restrict ourselves? As it turns out, I'm still a big proponent of 80 CPL limits for software projects written in high-level programming languages.
HISTORY
Although most typewriters had standardized on 72 CPL by mid century, IBM's well-known punch card system standardized the 80-character limit. This limit continued in the terminal interfaces of the next generation. Today, we don't have any such system-enforced limits, but many software development teams implement them anyway as a code style guideline.
SIZE STILL MATTERS
Even with today's huge screens, 80 characters per line is still helpful. Many developers use IDEs or tools like Vim to display multiple source code files side-by-side on screen.
80 CPL is great because it lets developers view two source files side-by-side on most laptops screens with a reasonable font size (10-16 pt. range).
KEEPING IT TERSE
More importantly, though, having an 80-character limit forces developers to constrain the amount of logic in one line of code. Do you really need that ten-method chained ActiveRecord query on a single line? Hitting the 80 character limit is a great indication that you should refactor your code and break things out so they're more readable.
Does your software team enforce a characters-per-line limit?
HISTORY
Although most typewriters had standardized on 72 CPL by mid century, IBM's well-known punch card system standardized the 80-character limit. This limit continued in the terminal interfaces of the next generation. Today, we don't have any such system-enforced limits, but many software development teams implement them anyway as a code style guideline.
SIZE STILL MATTERS
Even with today's huge screens, 80 characters per line is still helpful. Many developers use IDEs or tools like Vim to display multiple source code files side-by-side on screen.
 |
| Vim session split vertically with 80 CPL source code |
KEEPING IT TERSE
More importantly, though, having an 80-character limit forces developers to constrain the amount of logic in one line of code. Do you really need that ten-method chained ActiveRecord query on a single line? Hitting the 80 character limit is a great indication that you should refactor your code and break things out so they're more readable.
Does your software team enforce a characters-per-line limit?
Tuesday, January 7, 2014
2013 Web Technology Year in Review
I just finished an article for Panoptic Development about some of my favorite web technologies for 2013. In the article, I discuss Rails Admin, Meteor.js, and the latest versions of the Django web framework. Check out the article here!
Wednesday, October 16, 2013
Wicked Good Ruby Conf Roundup
I recently returned from Boston's Wicked Good Ruby conference, and it was one of the best regional conferences I've attended. Not only was the speaker lineup top-notch and the content itself compelling, but I was especially impressed with the attendees.
Don't get me wrong - I always have fun discussions with Ruby conference attendees. But I've been especially impressed with the attendees here, both the New England locals and the out-of-towners that flew in. The folks I've talked to worked in a variety of industries like healthcare, biotech, and in consumer startups. I've also talked to folks working in really diverse teams, from one person to one hundred.
Here are some summaries and slide links for a few of my favorite presentations.
Opening Keynote
Sandi Metz
This was a compelling keynote that drew parallels between the software engineers of today and the typesetters in the newspaper industry decades ago. Both are stewards of the information age, so to speak, enabling the public to access huge amounts of information. The exact skill sets of both change and are frequently made obsolete. Sandi touched on some truly epic subjects, like getting satisfaction out of life, making every day cont, and embracing the impermanence of both career and life. As with most keynotes, it was grand in scope and depended heavily on the stage presence of the speaker. Sandi kept everyone engaged and I enjoyed it.
Wicked Bad Ruby
Matt Aimonetti
Slides
Matt's talk focused on the concepts of "good" and "bad" code, and what that means for developers. Matt's first point was that there is no such thing as "bad" code, as discussions of "good" versus "bad" are generally relegated to philosophy, ethics and the like. Matt states that code simply works or doesn't.
Along the same lines, developers aren't paid to write good code, they're paid to deliver great products. Matt advised the audience to understand what they're building - the business objectives, the timeline, the proposition value, the players, and the risk factors. Often, the right move isn't the generally-accepted best practice. Oftren, folks proclaiming "you're doing it wrong" don't understand the full context.
Taking a step back, Matt observed that we judge other people all the time, but we don't like to be judged ourselves. As developers, we make rules because of what we perceive we do well, and we think they always apply directly to other people. In other words, "you're doing it wrong because you did it differently than I did."
To sum things up, Matt recommended that we focus on the outcome while learning and improving. As he said, don't think as much about HOW you write the code, think about WHY. All in all, I really like this code craft-focused talk.
PEACE: Program Expertly in Corporations and Enterprises
Steven Haddox
Slides
This was a practical presentation about how to be a productive agile developer in enterprise (i.e. corporate) environments. Steve gave a lot of great advice here, and having consulted in the enterprise myself, many things really resonated with me. The presentation could be summed up thusly:
When working in the enterprise, fight for the following things, in order, until you run out of political capital:
1. Agile project management (and do a one month trial if you don't get buy-in)
2. Provisioned dev, staging and production servers
3. Key-based authentication
4. SCM
5. Issue tracking
6. Documentation/wiki
7. Error monitoring
I'm not sure if I got the ordering exactly right, but agile project management is definitely #1. :)
Naming is Hard
John Yurek
Slides
In this talk, John explored why naming things is difficult in programming. To quote Phil Karlton, "There are only two hard things in Computer Science: Cache invalidation and naming things."
Through some good examples and open discussion, John brought up some great points:
As with most of the Thoughtbot talks I've seen, this one had to do with "code as craft." It was a very good mix of both actionable advice and some general topics of reflection for software developers.
Market Analytics in Eve with Ruby
Doug Alcorn
Video (older version of talk)
Doug gave a very entertaining talk about Eve online, a MMORPG with a complex virtual economy. Eve has about 500,000 active accounts, and 30,000-60,000 players online at any one time.
Doug went over some basic information about game mechanics, types of players, and went through some interesting examples of gameplay.
Doug then went into detail on the deep player-driven economy, which is the "bedrock" of the game. Many economists, academics, and virtual traders actually play Eve primarily for the deep virtual economy, and the game's "Chief Economist," employed by CCP Games, is actually an Economics PhD.
Doug gave lots of examples of how items are traded in-game, and then discussed the huge amount of offline data that Eve makes available to players. CCP publishes a large REST API and allows users to scrape the in-game cache for information about item prices and upload to a third-party analytics site. This "cache scraping" is quasi-legal in the Eve world (it's not a bannable offense in itself, but it can contribute to other offenses); lots of players do it upload results to a third-party site to product accurate, real-time market data.
Doug went through some of the Ruby code he's written (namely, a Rails app) to pull in the latest market data, delete the stale data, and analyze the results. I got a chance to speak with Doug for a bit after the presentation, and he talked in more detail about the performance of his Rails application, hosting, and the Eve community in general. It was great to hear about Ruby in the context of online gaming, something we don't experience very often!
Towards Tooling; A Look at what is Missing from our Toolbox
Loren Segal
[Slides Unavailable]
In this talk, Loren discussed tooling in the Ruby language community. He first discussed tooling at a high level, talked briefly about tools that the Ruby community is good at, and finally explored areas where the Ruby community could improve.
Loren's observation: Humans have basically gotten to where they are because of their intellect and tooling. Tooling allows humans to become more efficient and build off the successes of previous generations.
Deployment, ops, testing: These are very good in Ruby.
Visualization, debugging, linting, static analysis: Ruby could be much better.
Loren pointed out that debugging front-end web development in say, Firebug or Chrome inspector, is inherently visual, and works well. Visual Studio has good tools like this, letting programmers visualize the entire call stack and easily trace execution. Ruby needs better tools to this end.
Loren briefly discussed some code complexity analysis tools, such as reek, flog and flay. These detect "code smells" but not common errors. This is in the domain of static analysis, which is lacking in the Ruby world.
Overall
This was a great conference, and even as a local, I'm continually impressed with the skills of developers in the New England area. If you have any of your own summaries or links to video from WGR Conf, let me know!
Don't get me wrong - I always have fun discussions with Ruby conference attendees. But I've been especially impressed with the attendees here, both the New England locals and the out-of-towners that flew in. The folks I've talked to worked in a variety of industries like healthcare, biotech, and in consumer startups. I've also talked to folks working in really diverse teams, from one person to one hundred.
Here are some summaries and slide links for a few of my favorite presentations.
Opening Keynote
Sandi Metz
 |
| Photo Credit: @wickedgoodruby |
This was a compelling keynote that drew parallels between the software engineers of today and the typesetters in the newspaper industry decades ago. Both are stewards of the information age, so to speak, enabling the public to access huge amounts of information. The exact skill sets of both change and are frequently made obsolete. Sandi touched on some truly epic subjects, like getting satisfaction out of life, making every day cont, and embracing the impermanence of both career and life. As with most keynotes, it was grand in scope and depended heavily on the stage presence of the speaker. Sandi kept everyone engaged and I enjoyed it.
Wicked Bad Ruby
Matt Aimonetti
Slides
Matt's talk focused on the concepts of "good" and "bad" code, and what that means for developers. Matt's first point was that there is no such thing as "bad" code, as discussions of "good" versus "bad" are generally relegated to philosophy, ethics and the like. Matt states that code simply works or doesn't.
Along the same lines, developers aren't paid to write good code, they're paid to deliver great products. Matt advised the audience to understand what they're building - the business objectives, the timeline, the proposition value, the players, and the risk factors. Often, the right move isn't the generally-accepted best practice. Oftren, folks proclaiming "you're doing it wrong" don't understand the full context.
Taking a step back, Matt observed that we judge other people all the time, but we don't like to be judged ourselves. As developers, we make rules because of what we perceive we do well, and we think they always apply directly to other people. In other words, "you're doing it wrong because you did it differently than I did."
To sum things up, Matt recommended that we focus on the outcome while learning and improving. As he said, don't think as much about HOW you write the code, think about WHY. All in all, I really like this code craft-focused talk.
PEACE: Program Expertly in Corporations and Enterprises
Steven Haddox
Slides
This was a practical presentation about how to be a productive agile developer in enterprise (i.e. corporate) environments. Steve gave a lot of great advice here, and having consulted in the enterprise myself, many things really resonated with me. The presentation could be summed up thusly:
When working in the enterprise, fight for the following things, in order, until you run out of political capital:
1. Agile project management (and do a one month trial if you don't get buy-in)
2. Provisioned dev, staging and production servers
3. Key-based authentication
4. SCM
5. Issue tracking
6. Documentation/wiki
7. Error monitoring
I'm not sure if I got the ordering exactly right, but agile project management is definitely #1. :)
Naming is Hard
John Yurek
Slides
In this talk, John explored why naming things is difficult in programming. To quote Phil Karlton, "There are only two hard things in Computer Science: Cache invalidation and naming things."
Through some good examples and open discussion, John brought up some great points:
- If you can't name it, it's probably wrong.
- If a method has one primary function, it's easier to name.
- In longer methods, you should extract functionality into aptly-named private methods.
- The act of refactoring and extracting code reveals that code's meaning and intent.
- A test's name should be its justification, not a description of "what" the code does.
As with most of the Thoughtbot talks I've seen, this one had to do with "code as craft." It was a very good mix of both actionable advice and some general topics of reflection for software developers.
Market Analytics in Eve with Ruby
Doug Alcorn
Video (older version of talk)
Doug gave a very entertaining talk about Eve online, a MMORPG with a complex virtual economy. Eve has about 500,000 active accounts, and 30,000-60,000 players online at any one time.
Doug went over some basic information about game mechanics, types of players, and went through some interesting examples of gameplay.
Doug then went into detail on the deep player-driven economy, which is the "bedrock" of the game. Many economists, academics, and virtual traders actually play Eve primarily for the deep virtual economy, and the game's "Chief Economist," employed by CCP Games, is actually an Economics PhD.
Doug gave lots of examples of how items are traded in-game, and then discussed the huge amount of offline data that Eve makes available to players. CCP publishes a large REST API and allows users to scrape the in-game cache for information about item prices and upload to a third-party analytics site. This "cache scraping" is quasi-legal in the Eve world (it's not a bannable offense in itself, but it can contribute to other offenses); lots of players do it upload results to a third-party site to product accurate, real-time market data.
Doug went through some of the Ruby code he's written (namely, a Rails app) to pull in the latest market data, delete the stale data, and analyze the results. I got a chance to speak with Doug for a bit after the presentation, and he talked in more detail about the performance of his Rails application, hosting, and the Eve community in general. It was great to hear about Ruby in the context of online gaming, something we don't experience very often!
Towards Tooling; A Look at what is Missing from our Toolbox
Loren Segal
[Slides Unavailable]
In this talk, Loren discussed tooling in the Ruby language community. He first discussed tooling at a high level, talked briefly about tools that the Ruby community is good at, and finally explored areas where the Ruby community could improve.
Loren's observation: Humans have basically gotten to where they are because of their intellect and tooling. Tooling allows humans to become more efficient and build off the successes of previous generations.
Deployment, ops, testing: These are very good in Ruby.
Visualization, debugging, linting, static analysis: Ruby could be much better.
Loren pointed out that debugging front-end web development in say, Firebug or Chrome inspector, is inherently visual, and works well. Visual Studio has good tools like this, letting programmers visualize the entire call stack and easily trace execution. Ruby needs better tools to this end.
Loren briefly discussed some code complexity analysis tools, such as reek, flog and flay. These detect "code smells" but not common errors. This is in the domain of static analysis, which is lacking in the Ruby world.
Overall
This was a great conference, and even as a local, I'm continually impressed with the skills of developers in the New England area. If you have any of your own summaries or links to video from WGR Conf, let me know!
Wednesday, October 2, 2013
Upgrading Legacy Applications: Ruby 1.8 Pitfalls
When dealing with large, long-lived enterprise apps, the upgrade cycle is often much slower. Because these applications aren't always under active development, the prospect of "long-term support" releases becomes more important.
We recently upgraded a client app from Ruby 1.8.7 to Ruby 1.9.3, just as support for Ruby 1.8.7 was ending. We ran into some "gotchas" while upgrading, so perhaps these will help other developers in the future.
In general, the incompatibilities between Ruby 1.8 and 1.9 are well-known, but we discovered a few lesser-known issues during this upgrade.
1. Array#to_s
In Ruby 1.8, calling to_s on an Array is equivalent to calling join.
In Ruby 1.9, calling to_s on an Array is equivalent to calling inspect.
This seems like a minor change, but it is significant. There are many Ruby 1.8 libraries that will display arrays directly to users via to_s, assuming the array will be suitable for display directly to an end-user.
If that code is run against Ruby, 1.9 the displayed array will include both the brackets and commas, usually making it unsuitable for end-user display.
2. Symbol#to_i gone
As of Ruby 1.9.2., symbols are no longer internally represented as integers and Symbol#to_i was removed (thanks to andrewjgrimm for pointing this out). Thus, if you call string_object[:symbol], it will use the symbol's integer representation to reference an element under Ruby 1.8.
3. Creating Hashes
In Ruby 1.8, you can actually create a hash by putting an list of keys and values directly in the curly braces. In Ruby 1.9, that doesn't work.
KEY TAKEAWAY
Backwards compatibility in languages is important, especially when building enterprise applications. Even if a seemingly-arbitrary change looks like a net win for program correctness, it can cause problems in legacy software.
For example, consider the following code:
Let's say you have a bug in method_that_returns_a_hash, and it sometimes returns a String instead. Under Ruby 1.8, that bug might be completely innocuous, because address_map[:canada] would still return nil, and your program could still execute correctly. Under 1.9, that would raise an error.
What other obscure incompatibilities have you encountered while upgrading legacy software?
We recently upgraded a client app from Ruby 1.8.7 to Ruby 1.9.3, just as support for Ruby 1.8.7 was ending. We ran into some "gotchas" while upgrading, so perhaps these will help other developers in the future.
In general, the incompatibilities between Ruby 1.8 and 1.9 are well-known, but we discovered a few lesser-known issues during this upgrade.
1. Array#to_s
In Ruby 1.8, calling to_s on an Array is equivalent to calling join.
In Ruby 1.9, calling to_s on an Array is equivalent to calling inspect.
This seems like a minor change, but it is significant. There are many Ruby 1.8 libraries that will display arrays directly to users via to_s, assuming the array will be suitable for display directly to an end-user.
If that code is run against Ruby, 1.9 the displayed array will include both the brackets and commas, usually making it unsuitable for end-user display.
2. Symbol#to_i gone
As of Ruby 1.9.2., symbols are no longer internally represented as integers and Symbol#to_i was removed (thanks to andrewjgrimm for pointing this out). Thus, if you call string_object[:symbol], it will use the symbol's integer representation to reference an element under Ruby 1.8.
3. Creating Hashes
In Ruby 1.8, you can actually create a hash by putting an list of keys and values directly in the curly braces. In Ruby 1.9, that doesn't work.
KEY TAKEAWAY
Backwards compatibility in languages is important, especially when building enterprise applications. Even if a seemingly-arbitrary change looks like a net win for program correctness, it can cause problems in legacy software.
For example, consider the following code:
Let's say you have a bug in method_that_returns_a_hash, and it sometimes returns a String instead. Under Ruby 1.8, that bug might be completely innocuous, because address_map[:canada] would still return nil, and your program could still execute correctly. Under 1.9, that would raise an error.
What other obscure incompatibilities have you encountered while upgrading legacy software?
Wednesday, February 27, 2013
LA RubyConf Presentation: Python for Ruby Programmers
I just returned from the 2013 Los Angeles Ruby Conference. The conference was great! The presentations were very good, the venue (Marconi Auto Museum) was awesome, the food truck lunch was delicious, and overall, it was a very high-energy conference!
I gave a talk called "Python for Ruby Programmers," exploring the design decisions and "spirit" of each language. Check it out!
PYTHON FOR RUBY PROGRAMMERS
I gave a talk called "Python for Ruby Programmers," exploring the design decisions and "spirit" of each language. Check it out!
PYTHON FOR RUBY PROGRAMMERS
Thursday, January 3, 2013
Presenting at LA RubyConf 2013!
I'm very excited to announce that my proposal was accepted and I'll be presenting at the Los Angeles Ruby Conference on February 23, 2012.
I'll be giving a talk, "Python for Ruby Programmers," to familiarize Rubyists with Python and give them a better sense of Python's relative strengths and weaknesses. We'll talk syntax, maintainability, and practical applications.
More information coming soon!
I'll be giving a talk, "Python for Ruby Programmers," to familiarize Rubyists with Python and give them a better sense of Python's relative strengths and weaknesses. We'll talk syntax, maintainability, and practical applications.
More information coming soon!
Subscribe to:
Posts (Atom)