I recently gave a talk at the Drupal Camp NJ on Drupal Coding Patterns. You can listen to the entire talk, and view the slides and the code: http://www.drupalcampnj.org/content/drupal-coding-patterns.
This year’s RailsConf was truly one of the most impressive and inspiring development conferences I have ever been to. Bright-eyed and bewildered, I got to listen to lectures from people big and small in the community. Two individuals, in particular, stood out to me: Yehuda Katz and Rick Martinez. I listened to Yehuda’s keynote; the now Rails hero’s mentioned in his talk “I was just some guy who dove in, and here I am.” Rick Martinez of Flavorpill.com, who you may not know, is really just a guy who did dive in and was able to give a fascinating talk called “Hardcore Extending Rails 3.” The overall message? Again, “I just started digging around, and here’s what I came up with.”
As an aside, one of the questioneers at Rick’s talk was Yehuda commenting something to the affect of “this is what we wish more people would do, just dive in.”
I knew I had what it takes to dive in, it was just a matter of discipline and taking the time to learn the tools and get acclimated with the libraries. I walked into the conference feeling like a novice about to hear four days of lectures that were way over my head, and I left chomping at the bit waiting to start tearing to guts of Rails 3 wide open (which I began to do the entire trainride home).
For the past two months since then, I’ve been consuming more Ruby information then ever, determined to master the language and become a productive member of the Rails community. There have been frustrating times when I didn’t understand anything (and there will be more of that to come), but there has also been a wealth of knowledge that I have gained and have been able to apply immediately. For those of you who want to dive in, I’ve assembled this list of things I’ve done to get going and I think it could help you out, too. Pick and choose as you wish; these items may not all be for you, but if it’s on this list, it’s because I directly associate it with my growth.
Read The Ruby 1.9 Book
If you want to work with Rails, you have got to learn Ruby. Ruby is filled with new concepts and techniques that you probably haven’t experienced in other languages. The more of this language you know, the more you will understand the design patterns that the Rails library uses, and the more power you can leverage in your own code. The internal architecture of the code is a lot to take in, you don’t want to be hung up on Ruby syntax at the same time. Learning Ruby will help you separate whether what you are looking at is confusing because of your lack of understanding of the Ruby code or the Rails library (looking at the Rails lib after learning Ruby better, the code is so much easier to follow). Read “The Ruby 1.9 Book,” also known as “The Pickaxe Book.”
Learn Ruby Metaprogramming
Metaprogramming is the practice of writing code that writes code. Two weeks ago, I would have told you that Metaprogramming is something that the pros did because they’ve grown so bored with the boundaries of the language that they want to add to it. On the contrary, metaprogramming is a staple of working with Ruby and is a compliment of the language’s aesthetics. Learning about concepts such as Open Classes, Dynamic Dispatch and Methods, and beyond will help you understand how programmers wrangle Ruby to get it to work the way they want it to.
Here are three great resources resource for learning Ruby metaprogramming:
- “The Ruby 1.9 Book” book has entire chapter on metaprogramming. I recommend reading this before jumping into…
- “Ruby Metaprogramming” by Paolo Perrotta. This book explains metaprogramming concepts in a fun, observational way, with an entire section on metaprogramming Rails.
- As a follow up, Yehuda wrote an article that helps clear up some common misconceptions about how to properly write libraries – “Metaprogramming In Ruby”
By now you realize you’ve got a lot of reading to do, which is why I totally recommend that you…
Buy an iPad
This may seem like one of those “you-got-to-be-kidding-me” kind of todos. But the truth is, I single-handedly attribute so much of my educational growth over the past month to me buying the iPad. Last year, I bought the Ruby 1.9 book and the PDF. The book sat on my shelf and I only casually browsed through it. The PDF was on my laptop, and I only fired it up a couple of times, and then get distracted by a client’s email, or a blog post, and ultimately didn’t read any of it. With the iPad, I take it everywhere: I read for 15 minutes at the laundry mat, 30 minutes at then pool, before I go to sleep, etc. In three weeks, I read over 450 pages of the Ruby 1.9 book and over 250 pages of the Metaprogramming book. Here is the key though: make it an educational device only. For me, that meant not loading on a Facebook app or any other distractions, I didn’t even configure my mail account or add music to it. It’s simply there for ebook reading, reading RSS feeds and Tweets from other developers, and writing blog posts. It’s a productivity machine!
Read the Rails source code
While it may seem daunting at first, the current version of the Rails 3 library is one of the most elegant codebases to try and follow. Before taking the plunge into the codebase myself, I used to hear people say “look at the source” and I used to think “I am not at that level yet.” Trust me, you are, and the more comfortable you get with Ruby, the more you will learn how the Rails code plays into it’s strengths. Additionally, the library is filled with extremely helpful comments. For example, check out base.rb in ActiveRecord; don’t quote me on this, but I’m pretty sure for every line of code, there are two or three lines of comments.
When it comes to getting involved with Rails, you couldn’t ask for a better community to help you out then the Rails community. There are people with all different levels of expertise, willing to lend a hand to help you achieve whatever you’re trying to accomplish.
- Go to conferences and meet ups. Not only do you learn about emerging technologies, but you also get to network and make friends with other developers, as well as learn about other popular developers in the community. One key piece of advice: don’t be shy. Everyone is there for the same reason, and everyone I’ve gotten to meet in the Ruby community have been nothing but nice and helpful.
- The Ruby on Rails IRC on freenode, #rubyonrails. Don’t feel shy; just ask your question and be patient. Feel free to hit me up in there, I’d be more than happy to help you out.
- RailsBridge – RailsBridge is a group of people committed to helping you learn more about Rails. They can answer your questions in the #railsbridge IRC, they organize weekend bug mashes to help the Rails core team get through ticket issues in Lighthouse, and are really just a great group of people. I got to spend a good half hour chatting with Santiago Pastorino of WyeWorks at RailsConf, about RailsBridge and all the things they do, awesome stuff!
- Read up on the work other developers are up to. Guys like Aaron Paterson, Ilya Gregorik, and Yehuda Katz will commonly blog or tweet about things they are working on. You can learn a lot by being a fly on the wall.
The biggest piece of advice I can give you in terms of getting involved with the Rails codebase is: start. Any new library takes time to learn, and Rails is no exception. If you follow any or all of the tips I’ve listed, I think you’ll find the learning curve to be a little less steep. If you have any other advice that helped you out along to way, please leave a comment below, myself and others would appreciate it.
As I sit here in court, waiting patiently to fight a cell phone ticket that I am clearly guilty of, I got the opportunity to read over David Hansson’s recent post on deadlines. To recap, he stated that we should stop holding ourselves accountable to unrealistic deadlines, or better put, to deadlines that force us to sacrifice quality, testing or hours. This isn’t a new thought for any seasoned developer. While we dread the idea of slaving over late hours and patch-and-go design methodologies, we seem to constantly practice the former, and unfortunately the ladder.
While, I agree that we shouldn’t be pigeon-holing ourselves into tight deadlines, the truth is, most of the time, doing so will land you the contract, and refusing it will result in the client giving it to one of countless other developers who will gladly slave to meet that impossible deadline. So, how does one find a homeostasis where both the client and the developer are mutually happy with the quality of work and the amount of time it takes to build it?
For most development companies, three basic questions fuel the work we do, to a certain extent:
- What do you need done?
- How much can you can pay to get it done?
- When do you need it done by?
Armed with these 3 answers, you can derive a general synopsis of the life-cycle of a project. For a certain type of client, the first two questions are givens: the client needs these features and they only have a certain amount budgeted to get it done. Clients generally come to you with specific demands that they typically have good reasons for (and obviously, we will intervene if our experience tells us the demands need tailoring) As for budget, that’s always a touchy subject: we are resolute in what our labor costs will be, but sometimes, clients won’t budge and you still want to help. As a result, time may be your ultimate leverage when you gain the knowledge of the different ways time can factor in to a project.
Why is your deadline?
Steve Walker and myself spend a great deal of time debating certain points of our industry in hopes of carving out a strategy we refer to as “Client-Driven Development.” The idea is to shift the paradigm of many of the assumed truths of developing software for clients. One of the facets that interests me is the concept of a deadline. To explain, here are a couple of examples.
The arbitrary deadline
Scenario: The last web company I worked for believed in the arbitrary deadline as a means to engage their employees. A new idea would be conceived by the CEO and its deadline was always “the last Friday of the month,” regardless of rational, time estimate to develop the feature, or what day of the month it currently is.
Result: The net result was a company divided by people that knew the deadline was bullshit so they lost passion for the project (and eventually the company) and people that worked feverishly to meet this deadlines because “he’s the boss.”
The open-ended deadline
Scenario: Many times, you will work with a client who “doesn’t have a deadline”. The reasons why they do not vary, but many times I feel the client thinks they are being convenient by being very open-ended.
Result: The result of offering an open-ended deadline can have two general consequences. The first is that the developer may afford the client the ability to either negotiate the features or the budget. The second is that the developer will hold you to their estimate, but the project will never get done. You all know about that project that you have right now that started over six months ago but either you haven’t finished it yet because there is no client pressure, or the client has finished providing the content or approvals, also because there is no client pressure.
Note: having an open deadline is like getting in shape without weighing yourself first: sure, you may tell yourself “the amount of weight doesn’t matter, just as long as I look good,” and you still might even loose the weight. However, knowing your starting point and agreeing on the end point is the catalyst for realistic motivation.
Event Inspired Deadline
Scenario: A very common situation is for a client to come to you and say they need a project launched by a certain date because of a certain upcoming event, where ‘event’ is paralleled by a significant date to the client’s demographic. Some examples are trade shows, monthly newsletters, cultural events (ex. launching a red version of a site by Valentine’s day), or in tandem with a new product release, to name a few.
Result: As a whole, I find I am more accepting of these deadlines because they have a black and white reason for their necessity. The issue developers have with these deadlines is that, often times, they are given without much time to develop. “We have a trade show in 2 days and we want the this new section to go live by then,” or even more painful “We have a trade show in 2 months and we want this new section to go live by then,” and then you don’t get the content for it until two days before the deadline.
My suggestion to you is not to try to treat the deadline game in a one-size-fits-all manner, because all clients and projects are different. It’s just not realistic to think that every client will agree to the one way you are going to address deadlines. I have found it much more effective to analyze what type of deadline the client has and see how I can use that as an advantage against the other main aspects of the project. Remember that while the three points of a project – features, budget, and time – may always form a triangle, there are different types of triangles based on how you handle each vertex.
Sidenote: For those curious, I got the ticket thrown out.
Joey Naylor: Dad, why is the American government the best government?
Nick Naylor: Because of our endless appeals system.
As web developers, whether you are a designer or a programmer, you have to manage tons of information to complete your project as quickly as possible, and with all of the requirements of the client in mind. It doesn’t matter if you are a large web shop, or the freelancer starting out with a small number or projects, you need to be organized. Organization of data, feedback, tasks, contact information, assets, and any other requirements ensures that you can maintain the big picture of the project, all bullet points, and that you have a paper trail of where direction and decisions came from.
However, it seems that though every size shop requires the same things, we can’t all seem to settle on the same software to organize our projects. The one-man show doesn’t want to pay $24 a month for a tool that deprives him of time-tracking and is deeply ingrained in multi-user collaborative features. The large company has problems with its oversights: it doesn’t account for maintenance or non-project work items, it doesn’t organize e-mail tickets, it doesn’t incorporate invoicing, and other random nuances that large shops have. Therefore, large shops are forced to have a number of subscriptions to varying SaaS apps, with redundant data, making an uneasy experience for the workers. This is no slight of BaseCamp, the extremely popular software is just one of many who offer powerful tools for managing projects.
I have a vision for software that manages the way your web shop works, and not just how you organize projects. My ultimate goal would be to develop a turn-key application that allows companies large a small to handle the life cycle of a client and their project. We are at an amazing time in web development, where information accessibility and frameworks are turning hobbyist into professionals. Larger shops are at a huge advantage too, with an infrastructure in place, and the business world acknowledging having a web presence like never before, your revenue is only limited by your turnaround times.
That’s why I am calling on you, the reader from all walks of life, to tell me about your day-to-day work process as a web developer, and how you vision an organizational application to handle what you do. Please leave a comment below, and I promise not only to keep the development of this application customer-driven, but to also to give you beta invites (so make sure to include your email address!)
Thanks in advance!
- Client Management
- Project Management
- Web Development Specific Roles: Project Manager, Developer, Freelancer
- E-mail Maintenance Ticket Integration
- Create Billable Services – such as Email, Hosting, SEO, Consulting, etc
- Wiki / KnowledgeBase ( thanks Mikey Van )
- API for accessing/submitting information
As I sit here at O’Hare Airport, eyes burning from the lack of sleep, I’m finally getting to wind down mentally and really absorb exactly what I’ve learned from the 2009 An Event Apart conference in Chicago. As a long time ALA reader, I was absolutely pumped to come out here for the first time and take in some of the cutting edge information straight from the horse’s mouth: a collection of industry heavyweights and unsung heroes alike. Put on by Eric Meyer, of noted CSS fame, and Jeff Zeldman, known for his contributions to web standards, the conferences have firmly established themselves as providing the de facto standard as to the quality and gusto, that certain wow-factor, that our imaginative and creative peers crave when making substantial investments of time and money into our careers.
The conference was split among two days; the collective genre of the speaker’s topics from the first day focused more on the business side of web development, while the second concentrated on code, developments strategies, and concepts to open our minds and tries to nudge the industry forward.
If I had to give the conference an overall grade, it would be a B. It’s a grade that leaves you thinking “I wish it was an A, but I’m glad it wasn’t a C”, and that’s pretty much my reaction. While A List Apart is normally known for introducing new and high-concept topics, the conference seemed to amplify sentiments from the past year. To say I was unsatisfied would be a lie, but to say I was blown away would be one too.
Note: all photos beautifully captured by John Morrison – © 2009 John Morrison – subism studios llc – link
The brain behind Happy Cog, Zeldman gave a talk about ensuring we are solving the problem that we were asked to. He emphasized the importance of research to help fight your case, gain trust in your client, and ensure that you are addressing the task at hand. Don’t forget about tried-and-true software design principals, such as scenarios, to show how the site you are developing will address that research. My favorite section of his lecture was speaking about how to “learn to translate” what the client has been asking for: this is not their native thought process, so we should not assume what they are saying (or complaining about, more appropriately) is really what they want. The culmination of his lecture was to ensure we are addressing “the user, the research, and the problem”. When doing some personal site work, don’t forget that you get bored of your layout way before the rest of the world does.
Final Grade: B – Very solid topic, but played a little too safe for me.
Jason Santa Maria
Jason is a guy who leads by example, whether you like his ideas or not. Santa Maria spoke about a point that most will agree with: even though we constantly think about “the big picture”, but realize much of the UX lives within the small details and nuisances that give a site it’s personality. For this reason, his first of three take-aways was to keep a sketchbook, a topic which he wrote about back in April (which was the main reason I started to keep a sketch book on me at all times), so that you are good to go whenever those ideas, big or little, come along. Topic number two was to incorporate a grid system, whether a pre-packaged one like 960, the up-and-coming Blueprint, or rolling your own. In addition, he suggests thinking horizontally as well as vertically; we constantly think about columns, but horizontal content chunks help to maintain consistency even if you vertical layout needs to change ( see Jason’s site, jasonsantamaria.com ). Lastly, point three was his take on how to use fonts, suggesting that you should try to stick with one serif font and one sans-serif font.
Final Grade: C – The sketchpad idea is very important and related well to “thinking small”, but the grid section didn’t seem as relevant, and the font ideas just seemed very opinionated.
An amazing take on what could have been a topic dowsed in buzzword fluff. The head of Brain Traffic, she spoke of how to better integrate content into the life-cycle of the projects, a method BT used to produce a range of satisfied customers from state universities to Target, alike. In addition to site maps and page tables, she suggests using a “content inventory” system to audit a pre-existing site to know exactly what you have out there for visitors to see ( a system which I have already used with a client, only 4 days after she informed me about it). The net result is building a stronger brand, better audience targeting, and more optimized content for search engines.
Final Grade: A – For me, Kristina optimized the level of new and credible knowledge that loyal ALA’ers are accustomed to.
Following in perfect suit, Dan Brown, author of the must-have Communicating Design, introduced “concept models” – a new approach for identifying content relations for a more potent information architecture. Similar to RDB mappings in idea, not only did he introduce the concept, but he walked through procedures of defining and developing the models, the common patterns to look for, and he backed it all up with real world examples.
Final Grade: A – Just like Halvorson: introduce your concept, explain it, show the details, give solid examples. Very direct idea, which was extremely valuable, and instantly usable.
True to her New York roots, Hess spoke about a sort-of guerrilla approach to developing a user experience. She walked us through some cases studies, including how Iridesco, creators of Harvest, hooked up their contact system directly to a G-mail account, and built a back-end feature request system, to build what the users want, and not what the development team thinks they want. Her main take away point was you can upgrade your UX by design research, web analytics, usability testing, and experimentation and iteration.
Final Grade: B – Hess not only helped dissect UX into very graspable components, but also gave the common man techniques to implement on their projects now.
What isn’t there to say about this upstanding gentleman? After suggesting that he was a secret agent in a past job, I then went on to listen to his lecture about “tearing down the walls” by designing in the browser. As a developer who masquerades himself as a designer, I am all for designing a site in the browser; after all, it is the medium we are addressing – the main selling point of Clarke’s lecture. Designing in the browser allows for more interactive mock-up reviews (rollovers, mouse* events, etc), faster edits to fonts, and it addresses browser anomaly issues up front, rather than after a client approves a lifeless mock-up. The technique is also extremely powerful for rolling out multiple template mock ups in a faster manner, as examplified in a case study for the New Internationalist (note: as of 10/19/2009, his design isn’t implemented).
Final Grade: B – I applaud Andy’s efforts on presenting a topic that antagonizes the recent photoshop-fluff site mantra that has emerged over the recent years, but find that his technique only stands for a certain category of clients that do not desire a “pixel-perfect” design. While I wish we would openly adopt his design technique, it’s going to be a while until we get there.
Final Grade: C – To quote a tweet I posted immediately following his lecture “Am I the only one who feels like they were expecting more from this topic? Everyone seems kind of pumped …I kinda feel like ‘and…’”. I am a huge fan of Meyer, but a recap on the products of a technology that most professionals are already familiar with and use everyday is not what I was expecting from the industry giant.
Simon wrote about “building stuff fast and getting it approved”: his lecture outlined ways to develop products faster using new, agile-esk techniques. A core creator of Django, the python web framework, he mentioned the ability to utilize tools in your given development language to prototype faster: Firebug for CSS/JS, IRB for Ruby, BeanShell for Java, etc. He then spoke about the ability to use JSON with padding (JSONP) to quickly build apps using APIs from other sites. Additionally, he talked about YQL, Yahoo!’s content query system, “/dev/fort”, which was he and a group of his peers locking themselves in a fort in England to conceive, design, and develop a site from start to finish, hack days, screen scraping, open source, and git hub.
Final Grade: C – If you haven’t already gathered, his lecture was incoherent and erratic. Willison definitely seems like a guy with a lot of great insight, but he needs to really work on tightening it up to an obtainable stream of conscience.
An in depth evaluation of the psychology of forms, brought to you by the man who, literary, wrote the book on the topic. Luke took us through very well known examples of web forms, including PayPal, Amazon, and LinkedIn, to illustrate common pitfalls with form design. He presented us with findings of his research into how users respond to forms with vertical label alignments (better for ease of use) versus horizontal label alignment (better for updating). He used heat maps to display how visitors navigated through certain forms, gave a detailed analysis of how to use client side validation, and whimsically took us on a “who’s who” of screwed up web forms.
Final Grade: A – I may go out on a limb and say that this was my favorite lecture. Definite ALA material, Luke presented forms in a way I’ve never heard before. Also, he definately walked away with the quote of the event, “This is the web … fix it”
Rubin’s lecture on “Designing Virtual Realism” was a walk-through on the world of interface design, and how it relates to the web. His big takeaway point was that great design explains itself, and that a natural feeling interface will create the illusion that an application actually performs better.
Final Grade: C – Reminiscent of Simon Willison’s “buck shot” approach to lectures, it was sort of hard to follow. Half way through, his speech turned from creating realism to adding textures to your background. When it was all over, I’d be lying if I said I felt like I learned something.
Wrapping up the event was a very hands-on approach to demonstrating the power of CSS3, combined with that tactful approach of progressive enrichment. Through the use of his very elegant demo site, dowebsitesneedtobeexperiencedexactlythesameineverybrowser.com, Dan shows us how we can add little hints of new CSS properties, even though not all browsers will render these styles the same across the browser spectrum, by utilizing eight techniques, one of which is to start using RGBA.
Final Grade: B – Dan confidently walked us through a barrage of new CSS techniques, and alluded to a bunch of great techniques that I have no doubt we will start to see emerging as trends in the upcoming years.