May 16

It Takes All Kinds

After reading a blog post provocatively called “Today I accept that Rails is yesterday’s software” I felt the need to reply. I’m not sure why, I’m not going to convince anyone of anything, definitely not the author of that post. I want to reply because Rails is my current platform of choice, and let’s be honest, seeing a blog post with a title like that getting passed around makes you squirm a little. I think it made me squirm in a good way, because it caused me to step back and evaluate what I’m doing, and why. Enough with the back story, on with the show…

It always comes back to the tools. Everyone blames the tools. And there is good reason for that. Tools empower us. Tools hold us back. Tools excite us. Sharp tools allow us to stab ourselves. Dull tools don’t allow us to get much done. Some tools are optimized for safety. Some are optimized for speed. Some tools are optimized for flexibility, others push you down a happy path. But at the end of the day, they are tools. The only value they have is in what you can create with them. Your tool can be safe, efficient, shiny, but if no one uses it, it is just a dead lump of code.

These tools we have allow us to create amazing things. Many of these tools are quite complex. They try to hide a lot of that from us, but at the end of the day, modern web applications are complex beasts. Anyone involved in the creation of a web application knows that there are so many moving parts and pieces involved that it is mind boggling. There is no way you could fit everything you need to build a website into a single framework, even a framework as large as Rails or Django.

And you would never want it that way, everyone needs to do something different. You need a framework that is optimized for what you’re trying to do. The framework is there to provide us with a doctrine and the ecosystem that builds up around it is what makes it powerful.

What are you optimizing for?

Everyone is optimizing for something different. Is Rails a good choice for every shop? No way. Is it a good choice for your shop? I don’t know. What are you optimizing for? Are you a big team that is looking for safe tools which allow you to reliably refactor and give you a lot of compile time safety? Then Rails would be a terrible choice. Are you a small/medium development shop who needs to be able to stand up and maintain an application easily while leveraging a huge amount of community code/knowledge to get that done? Then a framework like Rails/Django/Laravel might be just the thing you need.

Alternatively maybe all of your developers know Python, then go with Django! The whole point is that you should pick tools/techniques that fit your team, don’t just grab the newest hippest tool off the shelf unless it solves some very concrete problems you currently have, or you are going to feel some pain. Maybe a lot of pain. And I don’t mean the kind of hand-wavey “we can do better” type problems, I’m talking about solid technical problems that you can put your finger on.

Looking for something better, or just different?

In the post I mentioned above it sounds like the author has a lot of frustration with his tooling. I’m sure that is something that everyone has experienced. I can’t speak to his exact issues, we don’t seem to have many of the same issues, but that doesn’t mean they don’t exist. Just as an anecdote though, I have often found that developers working in a framework for years get a ‘boiling the frog’ moment where they just accept poor ergonomics in their environment for years until someone new comes along and points them out, or they just lose their mind and flip out. Once you look for a solution, you’ll often find that it was a problem in your workflow all along, because more often than not, broken tools don’t stick around in the open source world. Can’t say the same thing for other ecosystems though.

The whole point is, don’t throw out the baby with the bathwater. These frameworks are complex. Software is complex. Sometimes they don’t play well together, but if you’re running into silly problems with your tools then you should be looking for solutions, not to throw everything out and reboot. If you’re a consultant, then those types of reboots can more easily occur, and are often very lucrative, but they are rarely good for your clients.

My problems aren’t your problems.

I constantly find myself waxing to other developers about how we, as a group, seem to be stuck in the mindset that all developers have the same problems. The tools and frameworks that Facebook, Twitter, Google, etc… use must be the best, and because I want to be the best, I must use them. Well guess what, you don’t have the same problems they do. They have a virtually unlimited amount of developer time, you probably don’t.

Would I ever tell you to not use Elixir/Phoenix, Node.js, Revel, Iron, etc…? No, of course not, I don’t know what your problems are. But what I would tell you to do is to thoroughly evaluate each one based on your needs. What libraries do you need? What are you willing to write yourself? What is the longevity of the tools? What tools are available to you for deployment/hosting/management/troubleshooting? What is the skill-set of your team? These are all critical questions to ask when evaluating a platform, and if you’re not asking them then you probably don’t know what you’re getting yourself into.

Yesterday? Today? Tomorrow?

Is Rails yesterday’s software? Sure. So is PHP. So is C#. So is Python. So is every web framework that has come before. It is mature. It doesn’t mean that it isn’t today’s software, or even tomorrow’s. It just means that it has been around for a while. Are there better platforms out there? Depends on what you’re doing. Are there better frameworks for what we do? Probably not. But I don’t know you and your problems, you have to make these decisions on your own. Taking ownership of that is always scarier than listening to a bunch of loud consultants and bloggers proclaiming that they have the future in their pocket.

It takes all kinds.

I tend to be harsh sometimes on developers who always jump on the new shiny tool, but the reality is that we need those people (even if I don’t want to have to maintain their projects). We need the trailblazers, because if we didn’t, there wouldn’t be a trail for the rest of us to follow. If Rails didn’t have those people 10 years ago then it wouldn’t be anywhere near where it is now. It never would have been able to push through those tough early years where running, deploying, hosting, and maintaining a Rails app was a really painful process. This is where a lot of these frameworks are now, and that is exciting. I really hope to see many of them mature into stable/reliable platforms and ecosystems. And one day, for what I do, another framework will pop up that will be a better choice than Rails. And I’ll probably move on to build amazing things with that framework.

But guess what, when that time comes, there will be somebody writing a blog post telling me my new platform is old news and I’ll quietly close my browser, fight the urge to write a blog post, and get back to work. Just like I should have done today.

May 12

Big Changes Are Afoot!

The last 6 months have been quite the whirlwind for me! My wife and I had our first child just over 6 months ago, and I’m starting to realize how much free time I had before that! He is wonderful, but it has forced me to push a lot of things aside in order to focus my time on him. I’ve been attending less conferences, writing less, and reading less. I still do way too much work after hours, but hey, I can’t just quit cold turkey!

Besides having my first child, the other big change that I am finally ready to announce is that Al Tenhundfeld has agreed to partner with me at Ecstatic Labs! I’m truly excited about working with one of my best friends, and at the same time I am also excited about what we are going to be able to accomplish. I am going to be rebranding CodeThinked to be the “official” blog of Ecstatic Labs, and both Al and I will be blogging on here. Hopefully that will bring the number of posts back to an acceptable level.

We can’t wait to see what the future holds! Thank you for all of your support!

May 09

A Technical Presenter’s Journey: Part 1 – Know Your Audience

I want to start a series of posts on tips for giving technical presentations. What I would really like to do is get tips and tricks from you, the reader, and then post them as a community driven series of tips on giving technical presentations. So here is what I need from you

  1. Either put up a blog post or just write a tip on giving technical presentations. Follow this post as a guide and just give a bit of info, tell a story, give a nice anecdote, etc… Have fun with it!
  2. Once you have done this, send me a message via my contact form and either send me the tip directly or give me a link to your post. If you send me a link to a post, I am going to copy the entire contents of the post, but with all of them I will give you a prominent link back to whatever site you want me to. There will be no pretending that it was my content!
  3. Sit back and smile knowing that you helped your fellow technical presenters! Then watch my blog over the next few weeks as I put up these posts. Or just come back at the end for a buffet of technical presenting tips.

And as a side note, I reserve the right to only use the tips that I deem worthy! :-) Ha ha, I just want to make sure there are no duplicates or poorly written content. (Except for my own!) So please tweet or blog about this so that this little experiment can be a success!

Continue reading →

Feb 09

Threads Suck, Just Abstract It!

One of my favorite quotes is by David Wheeler:

Any problem in computer science can be solved with another layer of indirection.

While this quote is certainly true, problems can arise when the layer of abstraction becomes too heavy. In .NET 2.0 the ThreadPool was introduced and it gave developers a very heavy abstraction over threads. It optimized the execution of multiple threads, but at the same time the developer was abstracted away from the individual threads so much that they lost a significant amount of control.

In .NET 4.0 the Parallel Extensions to .NET are now integrated into the core framework. This means that in the next version of Visual Studio we are going to get all of the new parallel programming features by default. One of these new features is the Task Parallel Library. This feature is a set of classes, called Tasks, which allow us to fire off actions asynchronously.

It looks something like this:

Task task = Task.Create(n => LongRunningMethod(test));

You might be looking at that and saying to yourself, “well, they just reinvented threads and called them tasks”. Well, that isn’t really the case. For example, the following two chunks of code are quite different:

Jun 08

Functional Programming Features in C# Presentation

I gave my functional programming features in C# presentation tonight and I wanted to make sure I got the code posted up. This presentation was all about the features in C# 3.0 that were borrowed from functional programming, not necessarily programming functionally in C#. Here is the presentation and source: Hope you enjoy!