has_many :thoughts

Well known blogger Amy Hoy presented about interaction between designers and developers. She claims to be both a designer and a developer and chatted about the processes that she and others use to successfully integrate the work of coders and artists. My take-away points:

1. Teaching your designer about Rails, even just a little bit, can go a long way to a successful working relationship. Get them comfortable with what they will expect to see in View templates when reviewing erb (or haml, etc.) templates created by the Rails developers.
2. Have the designer use subversion (or CVS, in our case…. for now). If the designer is using OS X (as most are), it won’t take more than a half hour lesson to educate them as to the virtues of source code control and the how-to of checking out, checking in, updating, etc.
3. Design cannot be an afterthought. Get the designer involved early in the process so that their perspective can be incorporated into the decision making process as much as possible.
4. Use wireframes to mock up the pages of your site. The wireframes can start as simple as napkin sketches, but should ultimately be fleshed out in some kind of box/text format. This is far quicker then any kind of direct-to-Photoshop process.
5. There are several “hand off” points that can be utilized to switch the process from designer to developer. This was sort of a no-brainer. Obviously, some designers can handle HTML, others can’t, and the process of cutting Photoshop files down to HTML and CSS can either be handled by the developers or designers. I would love to find a really good designer that embraces XHTML/CSS as much as I’d like them to. But until that point, I think we’ll stick to doing the HTMLification ourselves.

The theme of the first two talks I attended at RailsConf today was more business-y and less technical. There was a chat called “Teascript: A Homesteader’s Story” and one called “The Business of Rails”.

The former was a case study by a developer who decided to make his own niche web app and start selling a service around it. The content was interesting, however the talk itself was frustrating as he took all manner of questions all the time and there were zillions of interruptions with dull questions.

1. Get the idea out there fast and start getting feedback. This has always been my view, as opposed to bottling it up fearing that someone will steel your idea.
2. Read 37 Signals book, Getting Real. Apparently this is the bible of developing web apps the Rails way. I was ashamed when a show of hands indicated nearly everyone had read this book except me.
3. Start small. The speaker discussed the benefits of starting your application small with only essential features to get it out there. I’ve been thinking more and more this is the way to go so I was glad to hear this point.

The latter was a panel discussion with open questions from the audience and a panel of owners of Rails development shops large and small. This one was a bit dry because a lot of it was about how to quit your job and take the plunge. Which I did 6 years ago now.

We sometimes consult with clients on how to market their sites via search engines and other means.

I had a client email today requesting some tips on marketing their site and even getting listed at all on Google. I, of course, offered a full proposal but threw these basic free tips there way to ensure that they can at least be indexed:

1. Google (or any search engine) can’t see anything in images and anything in Flash. So use images as little as possible, same with flash, especially for navigation. If you must use Flash for links, make sure you have text links that Google can use to navigate through your pages.
2. Link text is very important. Use sane, relevant keywords as links between pages. Avoid “click here” as a link. (To see an example of how link text is important try Googling “leave”. You’ll find that Yahoo is number one and Disney is sometimes towards the top. This is because every porn site has a “Leave” button that links to one of those, right next to the “Enter” button.
3. Put your most important keywords on your homepage. Avoid any kind of “enter here” page with no keywords as your homepage.
4. Use CSS based layouts which have less markup and more keywords. Learn about how to do CSS image replacement for navigation buttons.
5. Get as many people as you can (with decent sites) to link to you.

Obviously, this is only the very beginning and many of these are even debatable. But following these basic practices will help ensure that a site can at least be indexed.

About 6 months ago now, we decided to switch all our web application development to Ruby on Rails from ASP Classic. At the time, I needed to sell my team (and myself and other business stakeholders) on investing significant company resources on a switch. And so I put together this list which I distributed to our team. At some point in the coming weeks, I plan to update this to why we’re sticking with Rails and I hope to incorporate it as part of the forthcoming commercial section of PhillyOnRails.org.

1. Faster Development
   • The initial tidbits I heard said that rails can help us develop applications faster, with less time spent on repetitive mundane tasks.
   • This is the reason I first started looking into Rails.
2. Model / View / Controller
   • The MVC forces us to separate business logic (models) from presentation code (views) and connect them together with functionality (controllers).
   • This will force us to produce more easily maintained applications, sites that can grow more easily.
   • We can create code that is more easily ported from one application to the next, because presentation code isn’t intermixed with logic.
3. DRY
   • The entire Rails architecture and community is heavily aligned toward the concept of Don’t Repeat Yourself.
   • This will help us stop repeating the same code in so many places. Less repetition means more efficient development.
4. Framework Features
   • As a web framework, Rails already does for us a lot of the little things we spend lots of time doing.
   • Like validation. It’s a couple of lines of code to produce server side validation that works really nicely.
5. Testing
   • The work we’ve been producing lately has been appallingly buggy. Even if the kind of mistakes we make are simple human errors, to the client, it’s a mistake and it causes something not to work.
   • Although we need to take better care to test the things we do, it would become cost prohibitive to test every single line of code on every single page of every site each time a minor little change was made. So…
   • Rails has built in testing functionality:
     • We can define specific results that should appear when specific actions happen.
     • Rails can automatically alert us when something we do in part A of the application breaks something that’s supposed to happen in part B.
   • Less buggy apps = happier clients = more clients.
6. Neat Language
   • The Ruby language itself is pretty different but I like it.
   • There’s certainly a learning curve but the object-orientedness of it is really powerful and makes writing it much more natural than other languages I’ve learned.
7. Source Code Control
   • Right now, most of the development we do is on live sites. When clients do ask us specifically not to do something live we end up having a ton of scripts to rename and change just to post things live.
   • Rails allows us to develop on our machines while the rest of the world isn’t hitting the application.
   • Although we could institute some source code control mechanism with ASP, it’s harder: licensing costs would be expensive to have all the 3rd party components
8. Open Source
   • Rails is open source and is most commonly used with other open source components such as MySQL.
   • Open source = less licensing fees to Microsoft
9. Learning is Never Bad
   • Learning something new is always a pain in the ass, but it will probably help us with our ASP applications, too.
   • Focusing on being DRY and paying more attention to testing in our Rails apps will hopefully have an affect on our ASP development too – which there will surely be plenty of in the coming months and years.
10. ASP Is Dead
    • Standard ASP 3 is going by the wayside – fast.
    • If we are possibly going to stay competitive with other web development shops, we have got to adopt new technologies.

Welcome to our blog.

Kinetic Web Solutions is a small team of developers who are evolving from an ASP website design/development shop into a Ruby on Rails web application development consultancy.

We hope to accomplish several goals by deploying this blog:

1. Establish a wider presence in the RoR community
2. Contribute some of our learnings back to society
3. Develop a stronger team sense amongst our employees
4. Create a central location for team members to share resources

So now I will stop yammering on and we’ll see if this deployment of Typo works.