Connection ⚡ Required

Why csscss doesn't remove duplication for you

2013-04-27T00:00:00+00:00

After I released csscss, I've been asked numerous times:

Why doesn't csscss remove duplication for me?

That is a fair question. It is easy to look at csscss and ask why it isn't more like a minifier that a developer can just run before deploying updates. In fact CSSO and css-ractionator are projects that do this exact thing.

So why didn't I build it that way?

csscss forces me consider my (code) design

I built csscss as a tool to help a developer write smarter CSS. Duplication isn't all bad, but we often write duplicated CSS unknowingly. When I see duplicated CSS, it forces me to think about my rules and structure. It forces me to ask myself several questions about my code.

"Is this necessary?"

"Have I already defined a structure for this? Do I need to extend existing structures?"

"Is there a better way to define the same rules?"

"Can I leverage other CSS tools to better structure these styles? (Sass, LESS, etc)"

All of these answers reduce duplication, but more importantly, they force me to consider the design of my code. And I don't think there is a single algorithm that satisfies all cases.

Now you can obviously do this without an automated tool. And it is easy for a small number of rules. However as your site/application grows it is extremely difficult to continue this mental juggling.

I like to think of csscss as a tool that helps extend my intuition, not replace it.

Generated code is harder to debug

If csscss generated new duplication-free code, all I am doing is punting work for later. Which usually comes up when I need to debug my styles from the browser. If the generated output is substantially different than the original source, it makes my job harder to fix my problems.

I have a similar problem with coffeescript, though I still enjoy using it. The coffeescript I write and the javascript I debug are different. Luckily, in that case I can follow the flow enough to jump back to coffeescript to fix my bugs.

However the point of csscss is not to optimize code, it is to help inform you about areas improvement. If csscss did this for you I expect the gulf between original source and browser CSS to be rather large.

Improving the CSS landscape

None of this is a knock against other developers working on the same problem. In fact, I think different perspectives and trial/error in this field can only be a good thing. CSS has been around for over a decade and it surprising to me that we don't have more tools. So I commend anyone spending time to contribute. csscss is my contribution based on my opinions.

Here are some others tools that people have mentioned since I released csscss.

csscss

2013-04-25T00:00:00+00:00

About eight months ago, I had an idea for a potential tool that could help refactor CSS. I wondered, "Why aren't there many (any?) CSS static code analyzers out there?"

I mean when you think about it, it is a little crazy. CSS is a pretty simple language and it has been around for over 15 years. The selectors can get a little intense and there is a laundry list of properties. But the core syntax of CSS is pretty straightforward.

The premise was simple. In all other languages, I work at writing DRY code. So why can't something inform me when I'm repeating the same declarations over and over? Better yet, I wouldn't need a browser to figure this out. I should have all information immediately available in the source code.

I had this idea eight months ago, and I am proud that I had the fortitude to stick with the project and launch it. So here it is.

World, please meet csscss.

Your Identity ≠ Your Code

2013-04-24T00:00:00+00:00

This was originally posted on March 16, 2012 when I worked with CollectiveIdea

This morning I started my day seeing this in my twitter feed:

Your identity ≠ Your job
— Kyle Steed (@kylesteed) March 16, 2012

I’ve been thinking about this idea a lot lately. And I think it’s a trap that developers (myself included) easily fall into. To make this idea a little more specific to developers: Your identity ≠ Your code.

As developers, we like to solve problems and get a kick out of that feeling that seemingly comes out of nowhere: “Yes! I solved it. I am all that is awesome!” (maybe I’m the only one who says that out loud). But at the same time we attach ourselves tightly to our code and will equate criticisms of our code as criticisms of us as a person. And lets be honest, while we all want to improve, it is difficult not to equate “this could be better” with “you should have been smarter”.

I don’t think it is entirely due to criticism either. There are developers that I look up to, and I still get geeked out when I’m lucky enough to talk with them. For most of my geek-heroes, I also see prominent projects that they are part of, and it is difficult to separate “they are awesome because they wrote x”. I know when I first began, I cared a lot more about how people would perceive the code I wrote rather than how well it solved the problem at hand. It is more important to view your web heros as people who ship working software. If you think they are the authority on how software should be written, you’re in for an awakening.

This idea also affects open source. It is rare to see a young developer submit bug fixes to existing projects. Most developers have the talent to fix outstanding issues, but don’t due to the fear of rejection and criticism. And again it isn’t the specific criticisms of the code they write, which in all likelihood would only accelerate their learning, it’s hearing those criticisms and taking it personal. It is hard not to take these criticisms personal, especially when you read someone else’s code and say “What the hell was this fella thinking? That moron.” Believe it or not, I’ve caught myself saying that only to run a git blame and discover I was the “moron” who wrote the code. Early in my career, after uttering something similar, I was told by another developer “Criticize the code, not the developer.” And that has stuck, though at times I have to remind myself.

We will look at a piece of code and think “This is God-awful. This dev is terrible”. And it’s important to remember there is a lot more context around why code is written a certain way. The original developer’s experience does have an effect, but think back to the hacks you have written and why they were necessary. Even if it can be written better, you’re not doing anyone favors by slamming the dev.

But then we wonder why we get defensive when we hear people sharing ideas about the code we write. “Yeah, they’re saying it politely, but I know what they’re really thinking.”

Cut the ego. Stop equating bad code with bad developers. Stop equating code criticisms as a knock against you as a person. We could use more people submitting ideas and less animosity around existing code.

My Thoughts on Refinements

2012-11-20T04:37:26+00:00

I have followed the various Ruby 2.0 refinements discussion for a little while now. There is certainly a lot of talk in the air for and against the inclusion of this feature. For those tuning in, here are some notable links to get you up to speed:

A presentation by Akira Matsuda at RubyConf 2012 introducing refinements along with other interesting new Ruby 2.0 (potential) features.
A thorough discussion by Ruby runtime developers
Another RubyConf 2012 talk by Brian Ford a prominent Rubinius developer.
A blog post by Charles Oliver Nutter a prominent JRuby developer.

I want to start off by saying, I have a ton of respect for the incredible work all developers have put into making my job a reality. The community wouldn't be where it is without all your hard work and sweat. And my career certainly depends on the fruits of your labor. Thank you.

There is an interesting mix of pros and cons for the inclusion of refinements in Ruby 2.0. I'm going to distil what I've read and my comments on the matter.

Current discussions

Implementation difficulties within MRI/JRuby/Rubinius/other

I'm just not qualified to weigh in on this area. I understand that there are some (many?) challenges in implementing this fully without breaking the principal of least surprise for developers. That may or may not sway everything else. It should certainly not be overlooked, but this isn't a scenario where you have people proposing code without writing it. Runtime developers are currently debating the feasibility implementation, and it does look split.

Crazy use cases

Many are cited on Charles' post such as:

What does the following do?

class Baz < Quux
  def up_and_add(str1, str2)
    str1.upcase + str2.upcase
  end
end

Josh Ballanco's example, also from Charles's post where

"the following code only refines the "bar" method, not the "foo" method."

class Yummy
  def foo(str)
    str.camelize # will error
  end

  using StringCamelize

  def bar(str)
    str.camelize
  end
end

I strongly dislike this argument. In complete fairness, you have no idea what String#upcase is going to do. Someone before the call may or may not have overriden the method. It could be alias_method_chain'ed to email my grandmother stock quotes upon invocation. No one knows. But we still love Ruby, we still get work done, and we still ship code.

Thinking of obtuse edgecases on the nastiness or confusion this could cause does not dismiss the potential possibilities. My initial reaction, and I think this is shared with many developers, is "Wow, this could really clean up some global-level monkey patching." That doesn't mean it will be used only for the forces of good.

Myron commented with some guidelines he uses when using monkey patching (which I think are great). But why wouldn't the same apply to refinements?

Saying that refinements could lead to dangerous and unusuable code does not dimiss the potential benefits of an incredibly flexible feature. Describe some of the existing features to a non-Ruby developer and watch their face either light up in possibility or scowl in disbelief. Like re-opening classes

What's wrong with monkey patching?

Brian Ford has asked this many times, and I don't think this is a great question to lead to the dismissal of refinements. Monkey patching is global and refinements are local to the call stack. I have not seen many great arguments won based on the fact that we can accomplish the same behavior through global means.

Things we should be discussing

Aside from language-level implementation details which some language developers seem to think isn't a problem and others do, I don't think the many of the current questions and discussions are productive. These are the topics I would like to hear discussed.

Is Ruby too mature to include something so experimental?

This might seem like a trollish question, but I think needs serious consideration. Ruby is not a young language with a small userbase. Sure we might be small when compared to the sea of C code written and deployed. But there is much more Ruby code in active use now than 5 years ago.

Changes this large has an affect on both the users who choose to use it, as well as those who don't. Are we reaching the point where this is too extreme? If so, where does an idea/implementation like this belong?

Ruby compatibility

The implementation of refinements was first proposed and then implemented by Shugo Maeda in MRI. Both JRuby and Rubinius have been fighting for RubySpec for many years, and there has been no effort to spec this feature.

Think about that. A prominent MRI runtime developer thinks about an implements an interesting feature, it is brought into the most popular runtime used, and the developers tasked with keeping up compatible runtimes are now forced to implement the same feature in their respective environments.

I get why JRuby and Rubinius developers would not be terribly motivated to do that without an argument.

Here is where I think MRI and JRuby/Rubinius have competing goals. MRI is continuing to push the boundaries of how to express the Ruby language in new ways. Whereas JRuby/Rubinius are forced to play catch up with large features. I don't mean that a knock against JRuby and Rubinius, because they certainly bring their own unique things to the table. JRuby has an amazing capacity for concurrency by leveraging the JVM and Rubinius has rethought even the simplest things such as a fully supported debugger.

On top of playing catch up, JRuby/Rubinius continues to advocate to developers to try their runtime and highlight successful production uses. It's difficult to convince developers to use your runtime if you have to change a large swath of code in the process.

This doesn't mean JRuby/Rubinius developers are fully biased against new ideas. It just means to me that they are heavily incentivized to fight highly experimental features coming from a different runtime. Like refinements.

Communication

The number one thing I think we should be discussing is "How did we get into this situation?" Many developers think refinements can be used in good/productive ways (myself included), but why are many smart, respected developers vehementely against it? Apart from language maturity or incentives for/against, I think this entire argument suffers from what countless arguments in the past suffer from: lack of communication.

MRI is largely written by Japanese developers, but has become heavily adopted in the United States. JRuby/Rubinius developers are predominately English speaking. There are many developers who speak multiple languages, but not enough.

Brian Ford mentioned this in the talk I listed above, though I think he could have presented that topic in a much more tactful, less rushed way. He proposes that we should all be discussing these features in English.

If I was a Japanese MRI developer, I would be offended by the way that was presented. First, there are many Japanese developers who have done a great job discussing very complex topics in English, just browse ruby-lang. I think they should be highlighted, or at least given some sort of props for their efforts.

Second, I can't help but put myself in their shoes. If I built some awesome wizbat that I continued to care for but over the course of time happened to be largely adopted by Russian developers. I would be a bit upset if they criticized me for not discussing development issues in Russian. Nothing against Russian, I just don't speak a lick of it.

On the other side of the coin, developers of JRuby and Rubinius are being forced to implement some very difficult features in their runtimes. Reading the dialog, it sounds like Charles' and Brian's complaints are being heard but perhaps not discussed as thoroughly as they probably should be.

I do not have any good suggestions for this problem. But I do think this is the crux of it. In fact, this is most likely a frustration that has been worked through for many years and refinements has now been the place to plant the flag and have it out.

Should refinements be in Ruby 2.0?

I think refinements offer some very interesting possibilities. It might turn out to be a disaster or the to key to triggering some amazing innovation in a caffeine-hyped developer. But instead of dividing the community by campaigning for or against its inclusion. I think we should be discussing matters that led us here, and will inevitably lead us to other disagreements if left unresolved.

Big Changes Again. Joining Collective Idea.

2011-02-03T16:08:50+00:00

Last year I felt compelled to start Connection Required. Not because I was forced to, but because I wanted to prove to myself that I could start and sustain a business. There is a sense of pride that comes with helping clients and making money from your efforts. I've encountered many surprises over the past year, mostly positive. This month, I'm going to be making another big transition and I'm joining Collective Idea.

Why would I join another company rather than sticking with Connection Required? It isn't because I am unable make it work. I've launched several successful projects, made my clients extremely happy and made money in the process. My family was able to move back to Northern Michigan. I've been able to spend more time at home than ever before. And I have had to push away as much work as I've accepted. All in all, I consider that successful.

However, when I consider what I want Connection Required to become, I pause. I do great work, but that doesn't mean I want to grow a consultancy and start hiring other developers. Enter Collective Idea. I've known these guys for a while. They're an extremely sharp group and they build great software. At Collective Idea, I can continue to do what I do best: write great software and make clients happy. But instead of being solo, I am able to join a team of developers who share that same goal. For those who have been in my shoes, you'll know, that's a big deal.

For those who haven't been in this situation, at a certain point you realize how few hours you actually have in a day/month/year. Sure I can work more, but then that takes away from my family. I can start hiring, delegating, and leading others, but that requires growing. And I'm pretty confident I'd make an awful boss :). There is only so much I can do as an individual, but as part of a great team I can be a part of awesome.

I'm excited about this transition because it's a step forward on many fronts. You can also read the announcement on Collective Idea's site.

Feel free to contact me at my new email address zach -at- collectiveidea.com. This site will continue to stay up, but will morph back into a blog over time.

Sharing a desk and internet

2011-01-19T20:31:05+00:00

After two months in the new office, I realized we're going to need to a lot more stuff to fill up the space: couch, big screen, etc. You know, the essentials?

Then I realized I could just bring in a new desk and offer up the space/internet for people who are passing through. Especially, since there are no coworking spaces in Traverse City.

So if you're in or around Traverse City / Elk Rapids, feel free to stop by. I do ask that you sign in through DesksNearMe beforehand so we don't overcommit the space.

New iPad App Deployed: Spatik

2010-12-23T17:40:23+00:00

For the past few months I've been helping Nicholas Patten take his vision and translate it into an iPad App. I'm proud to announce Spatik was accepted today and is now available in the App Store.

It's purpose is to bring Google Reader and Twitter to a user's fingertips (literally) and let the users schedule tweets. Spatik was a lot of fun to work on for me for a variety of reasons. While developing Spatik I learned more about:

Google's OAuth workflow, I had previously worked on Twitter OAuth on other projects.
The OAuth workflow within the iOS environment.
Having an iOS client interact with a custom backend server.
The App Store approval process.
The iOS human user interface guidelines and building custom interface components.

I will post more about the development lessons learned in other posts. But right now, I want the spotlight squarely on Spatik and Nicholas Patten.

Check out the app, give it a spin!

Tweetstream is now Web Scale

2010-12-22T19:14:51+00:00

Over the past few months, I have been working with Downstream on one of their products Tweetstream. In addition to building features, we have experienced a significant issue with the infrastructure.

Last night we pushed live a slew of updates and as a result the application is much speedier. The guys were so thrilled with the result that they wanted me to write a geeky technical post about all the changes for their users. You can read the entire article on their blog and also discuss it on Hacker News

December Northern Michigan Web and Mobile Meetup

2010-12-16T16:37:53+00:00

Last night we had our December Michigan Web and Mobile Meetup. We only had a couple guys due to family commitments, but that's understandable since we're only a week away from Christmas.

In the talk from last month, Gary Vaynerchuk mentioned Zappos and hearing about their rich company culture, we watched an interview by the CEO of Zappos, Tony Hsieh.

Before we watched the interview, we actually watched Jeff Bezos of Amazon give a short clip when they acquired Zappos:

Here's Tony's interview on BigThink.com.

Tony speaks a lot differently than Gary, but has a lot of insight on Business and Happiness. He mentioned Good to Great and having read that a few years ago, I heartily recommend it as well. He also mentioned Tribal Leadership which I'll be picking up soon. And of course there's Tony's book Delivering Happiness which I still need to check out.

I really appreciate Tony's perspective on culture and happiness. I also connected with his comments about the Millennials.

...there are so many people in corporate America where they're a different person at home on weekends versus on monday when they're in the office. And they leave a little part of themselves, or a big part of themselves at home ... maybe what the millennials are bringing to the forefront [is that] they can be the same person...

November Northern Michigan Web and Mobile Meetup

2010-11-19T14:06:46+00:00

Last night we had our second Northern Michigan Web and Mobile Meetup and I think this went better than our first. This week I grabbed a couple pizzas from Chef Charles in Elk Rapids, that guy can make a tasty pie. In fact I still have a couple slices leftover for lunch today. This week we watched Gary Vaynerchuk's RailsConf 2010 talk.

Gary has great stage presence, and I really connect with his messages in this talk. It also sounded like the group resonated with the talk and fed off his energy. We discussed items like caring about client relationships, the "Mom and Pop" attitude for tech and business, and hustling products.

I've set a date for the next meetup for December 14th. We may be at CityMac in Traverse City again, but I think it may be fun to mix it up and try out the Library. I'll firm up the location closer to the 14th.

If you're interested in Web, Mobile, and Business, I encourage you to stop by and hang out!

First Northern Michigan Web and Mobile Meetup

2010-11-02T13:31:07+00:00

Last Thursday we had our first Northern Michigan Web and Mobile Meetup meeting. While eating pizza, we watched an interview with Jason Fried and discussed it afterwards.

I had a pretty good time, and received some nice compliments on the format. Talking with the group, we may continue to watch and discuss interviews. I've set a date for the next meetup on November 18th. I'm still considering where we should go for the venue. CityMac was accommodating, but a few mentioned the meeting rooms in the Library.

If you're in the Traverse City area on the 18th, I encourage you to drop by!

HarvestApp.com Impresses Me Again

2010-10-21T21:12:44+00:00

I've been using Harvest for a few years now, and as a customer have been a big fan of their product. A couple months ago they made a change to their plans and impressed me again. This time though, it wasn't as a customer, it was as a developer and business owner.

It wasn't the details of the change that caught my eye, it was that prior to the announcement, they sent me an email regarding how the change affected an open source library I maintain.

Here's the email, posted with permission from Harvest:

Hi Zach

I'm reaching out early, before the official notification about this, to ask a question about your Harvest client: http://simplechatter.com/2010/04/harvested-a-new-ruby-api-wrapper/

In a couple of weeks Harvest will be implementing SSL across the board for all Harvest accounts. Accounts can opt-out of SSL (through Harvest support) but HTTPS will become the default for all Harvest access.

The net effect for accounts currently using non-SSL HTTP will be an HTTP 301 redirect from http://subdomain.harvestapp.com to https://subdomain.harvestapp.com when this change goes into effect for everyone.

Does your client support this 301 redirect, and SSL in general? If not, we'd like to work with you to support this, to avoid any issues for your access, or for anyone using your client.

Please let me know and feel free to contact me for any details, or if I can help in any way.

Thanks!

The fact that the company not only keeps tabs on the current software community around their product, and intentionally reaches out to them for potential issues, and offers to help out to fix those issues speaks volumes. Fostering a community and enabling evangelists around your product is often overlooked and under-prioritized.

Kudos guys, and keep up the good work.

Feel free to discuss this here and on Hacker News

The Pain of Launching Your Own Projects

2010-10-19T13:35:04+00:00

Ask anyone who has redesigned their own website or released an open source project, pushing something live can be painful. I think there are two primary reasons for this:

concern about making a great first impressions
the lack of constraints that are normally in place when working on client projects.

Launching and redesigning your own website is mentally tough. It's rarely a technical problem. Since it's your own site and no one paying you to build it, it can be very easy to keep adding features and polishing. Both of which delay the launch date.

Although they are often the source of stress, budgets and deadlines are useful. I've experienced if you embrace a constraint rather than ignore it, you will quickly re-prioritize the tasks and find innovative work-arounds for the largest tasks. We do this all the time when working on other projects, the trick is keep focused when working on your own projects.

Take this website for example. I went from PSD to Launched in 13 days (17 if you count the weekends). If this was a client project, that would be utterly horrible for this small site. However in the My-Project Timezone, that's not too shabby. Don't get me wrong, this site isn't perfect, instead it's littered with warts (none of which I'm going to point out). I didn't focus on building the perfect site, I focused on good enough for launch.

Pick a Deadline

After launching a few projects, I've learned a few useful tips. Pick a deadline and keep your feet to the fire. If it doesn't look like you can launch by that deadline, rip out features. One large wart for this site, is a missing portfolio section. That was a very intentional omission, one I have designs and even HTML/CSS for, but it was cut in favor of launching. If you're not a fan of deadlines, set a fake budget and track your time against it. That may even provide a more realistic picture on how you much effort you put into the project.

Polish After Launch

Another tip I've learned: polish after launch. We can become consumed with polishing and tweaking to the point that it holds us back. One advantage our projects have over client projects, is that there's nothing stopping constant polish after launch. If it's the critical eye of peers and competitors forcing you to make it perfect, stop and relax. Making a good first impression can drive us insane. It's important to remember projects don't stop at launch, they evolve over time. Get it to "good enough", launch it, then continue polishing.

Solve Simpler Problems

Finally, there are always going to be implementation issues that will get in our way. Our first reaction to figure them out, and that is great, but don't get hung up on it. It's okay to change course, alter the final solution, or even post-pone troubling issues. You're going to be forced to adapt, and you can either take the timeline-hit in figuring out the original problem, or you can change the problem and solve a simpler one.

I'm not advocating shoddy or half-assed work, I'm pointing out that launching is more important than perfection.

New Traverse City User Group: Northern Michigan Web and Mobile Meetup

2010-10-15T13:48:05+00:00

After we moved back home in Elk Rapids Michigan, one thing that I acutely missed was the number of user groups we had in West Michigan. Don't get me wrong, West Michigan doesn't have nearly as many compared to a metropolitan hub. In Chicago they even have a VIM Usergroup. But West Michigan did a lot of events going on, and active communities around them.

Instead of lamenting about what's missing, I decided to put together my own user group up here. Enter the Northern Michigan Web and Mobile Meetup which will have it's first event in two weeks at 6:00 PM October 28th at CityMac.

I have ideas on the direction and the topics this group could discuss, however I'm sure after a few months we'll hit a groove and discover what the group's focus is going to be.

So if you're in the Traverse City area on the 28th and feel like talking geeky feel free to drop by! Make it a point to seek me out and introduce yourself, I love meeting fellow tech geeks.

New Company, New Look

2010-10-14T11:37:13+00:00

I've blogged at Simple Chatter for a few years, but now it feels like a good time to retire that domain and roll it into a newer fresher look. Oh and while we're at it, why don't we create a new company?

World, meet Connection Required; Connection Required, meet the World!

This site will continue to be fleshed out in the coming weeks, but feel free to take a gander. And if you have a Ruby/Rails or iOS project in mind, feel free to drop me a line.

The visual hero crew did a great job on the design.

I think Twitter's OAuth-only Access is a Waste of Time

2010-09-03T19:41:57+00:00

I don't normally write sensationalist articles, but today I'm going depart from the norm and make a bold claim: I think Twitter's change to OAuth-only authentication is a waste of time for developers and businesses.

Don't get me wrong, I think the OAuth spec is slick and has very good intentions at it's core. Nor am I knocking it out of inexperience, as I've been building OAuth based applications for the past 6 months. However my primary gripe with Twitter's OAuth-only stance boils down to xAuth.

For those of you that aren't familiar with Twitter's recent change, before September 1st you could access their API by passing across your twitter username and password. This was fine if you were using your own credentials, however the Twitter ecosystem is rather large, and most people who interact with Twitter do it via a 3rd party service. The security issue is handing your password to an untrusted source. As of September 1st however, developers are only allowed to access the API using OAuth, which requires you to give your username and password only to Twitter and then Twitter will authorize the application on your behalf. Even I admit, the protocol is rather elegant. When it comes to Web applications, I can hardly argue the security. The user is already in a browser and being directed to Twitter and back mostly only fires up User Experience guys.

However, I have a huge issue with xAuth. xAuth is Twitter's solution to applications that have a large number of passwords already stored and allows the developers to convert them to OAuth-friendly keys behind the scenes. Well, from what I gather, that was the intended purpose. However there are many mobile Twitter applications out there only are using xAuth. Why does this tick me off?

1) As a user, I'm still giving my password to the application. The application is not supposed to store the credentials, however this is un-enforceable. At this point I'm only safe-guarded against applications that have their passwords stolen. I won't deny that's an issue, but not enough to force all developers to go OAuth-only.

2) Even Twitter's official client requires me to hand over my password. If Twitter is going to take the stance that all API usage is going to go through OAuth, I think they should eat their own dog food and redirect me to a mobile browser.

Do I dislike OAuth? Certainly not. And I know Twitter has some brilliant talent. But if Twitter is going to make OAuth vs Basic Auth this big of a priority, I think they are missing mark by moving a lot of applications to xAuth.

You can also discuss this further on Hacker News

A Public Comment To Those Enabling Abuse

2010-08-31T14:01:16+00:00

Michelle Greer recently wrote about viscous online comments on TechCrunch. Unfortunately, over the years I've seen a few ugly incidents where a female was singled out online and verbally attacked. To me, there is one thing worse than these gut-less commenters: it's telling a minority to "suck it up" or "don't take it personal" or "that's just the way it is" or "quit whining".

If you're someone who tells a minority to ignore abuse, you need to seriously reconsider your position. Because it is sickening.

You're running a marathon

2010-08-30T19:50:28+00:00

I'll be the first to admit it: I can work myself to death. Paul Boag recently wrote a great article about the false "badge of honor" regarding long hours in the tech field. I love what I do, and I am continuously grateful that I am able to make a decent living in software. But I'm also prone to burnout.

His article really hits home for me because I've been burnt out a couple times in the past. I'm still trying to improve my self-awareness, but unfortunately burnout is like bad breath: generally the people around you notice first. So far my main red flag has been "Do I feel like I'm sprinting from task to task?" Despite what some startups believe, running a company is a marathon.

Over the years, I've been approached by numerous people asking how they can break into software. How hard is it? How smart do you have to be? Which language is best? My main answer is always: to succeed in software you have to enjoy what you do and you have to be persistent. Software changes monthly, and sometimes it feels daily. At first enthusiasm will carry you through long hours reading and playing with new libraries and frameworks. But when you start picking up your 5th language and your 15th web framework, your motivation is primarily going to come from enjoyment. The key is realize you're not sprinting to an finish line. You're running a life-long marathon. I think the same philosophy applies to succeeding in business.

I almost edited the previous paragraph to say "career-long", yet when I quantify how many hours of my life will be spent earning a living, labeling it "career-" just doesn't seem appropriate.

There is nothing wrong with hard work and I am certainly not promoting laziness. However over-committing yourself or coming home unhappy is a recipe for disaster. Make yourself take enjoyment from your work and from outside of work. And if you can't, I wish for you the courage to make the necessary changes.

Client Satisfaction and Resources

2010-08-24T14:47:20+00:00

I've heard the argument "it takes Resources to provide good Client Satisfaction" and I simply have to disagree. Great client satisfaction has to come first, and the resources will follow. I also believe that companies who take this stance will often re-use those resources to provide even better client satisfaction.

Bargains

When most people think about making their clients happy, they think about bargains. A bargain is simply the same services at a reduced price. And that certainly is one factor in making clients happy, since who doesn't like saving money? Sadly, I think bargains are the first to come mind because they are so easy compared to the alternatives. "I'll just slash my prices and more clients will come." However there are other ways to provide value and make clients happier without taking a hit on price.

Craftsmanship

Some clients heavily prefer the quality of the service or product. If I'm in the market for a high-end acoustical guitar, I'm going to favor the quality of a guitar over the one with the best deal. This resonates strongly with software in the form design and often overlooked practices such as automated testing.

Listening and Solving the Real Problem

One of the most effective strategies I've found is: listen to the client and focus on solving the problem at hand. When I say "listen", I don't mean "hear the sounds coming from their mouth", I mean really listen to both what they are saying, and what they aren't. There are many clients out there who will pass on a bargain if it only partially solves their problem. I constantly hear stories from both other developers and clients about scenarios where developers ignored the problem at hand, and decided to solve a different one. They may work on an optimization issue when performance is acceptable, or decide to roll the work into an open source project when a specific and custom solution is really what's needed. Or build an exquisitely elegant design, that even I admire, yet it does not do what is requested.

This is not just applied to software. A friend of mine owns a couple local pizza and ice-cream parlors and he shared his experience: The best way to help an upset customer is simply to listen to them. Most of the time they're not wanting their money back or a coupon. They just want to know that their voice was heard and respected.

I always laugh at how appropriate this SNL clip is:

Experience

Sometimes clients just want a memory to cherish. A couple years back, my wife and I decided to go to a Ruth's Chris Steak House and we were amazed at the dining experience. It was certainly one we won't forget. When we were in Portland, we also had a fantastic night at the City Grill on the 30th floor.

In software, that's exactly the purpose field user experience design. Certain applications thrive by continuing to improve their interface to be as simple and effective as possible. Other applications thrive by removing options and choices from their customer base. A recent post by Scott Adams specifically addresses this point.

None of these points take significant resources to do well, and each of these can be improved with additional resources. Please share any successes or failures you've found. I'd love to hear them.

You can also discuss this post on Hacker News

Clients that Care

2010-08-03T15:08:25+00:00

Whenever a client hires me, I make it a very specific point not to bring baggage to the table. Whether it's other project scheduling issues, family schedules, strong toolset opinions, or any other demands on a freelancer's time or mental-space. Some clients will gracefully deal with a freelancer's baggage, but I've found that most clients would rather not have to concern themselves with it. As a result I work hard to guard my clients from that stress.

However, some baggage does inevitably come through. During the middle of July, we had a family emergency and I needed to immediately take off a couple weeks. Keep in mind two of the projects I was on were planning on launching at the end of July. So going offline that abruptly was a significant disruption.

I talked with each of my clients individually and I was relieved that they all took it well. After my first week out though, I was shocked at how thoughtful some of the emails/IMs/and Phone calls were. Here are a few snippets that I received:

"Just wanted to check in and make sure you were doing ok. Again, let us know if there's anything we can do."

"Obviously, do what you need to do for yourself. If that's work I'll be happy to keep you busy... We'd like to send some flowers..." (In response to me mentioning I may work on a feature to keep my mind busy)

"Take care and as much time as you need."

"Please take the time you need."

"Nothing comes before family. Take your time, when you're ready to start back up just let me know. No rush."

I've come to appreciate that my ideal client is not just a cool project nor a large budget, but instead a rich relationship. I feel very blessed that all of my clients are so considerate because there are many others out there who aren't.

Thank you Mike, Dana, Orlando, McHughson, Daniel, and Nicholas.

Why should I do business with you?

2010-06-17T12:58:36+00:00

All things being equal, people want to do business with their friends.

All things being not quite equal, people STILL want to do business with their friends.

- Jeffrey Gitomer in The Little Red Book of Selling

I love this quote and this book. Brandon Keepers posed a question over a couple beers (well OK, maybe more than a couple beers):

If a client asks you: "Why should I do business with you?", how would you answer?

It was a great question. I took a long pull of my Poet and stammered an answer. After thinking about the question a couple days, here's my (sober) answer "because I'm honest, I work very hard, and I have a blast doing what I do".

Here's the longer version:

Differentiators

I consider the following as ways for a company to set themselves apart from their competitors.

Cost : How much does it cost for your services or for your product?

Expertise and Experience : How much experience do you have with the tools you're working with and the problems you're working on? Are you considered a leader in your community?

Influence : Do you have an audience that your clients also wants to connect with? Do you have certain investment or new business contacts that your clients want you to make introductions?

Fundamentals

These are the fundamentals I feel successful businesses have to address if they want to provide value for their clients.

Authenticity : Are you honest are you about what you're selling and your ability to meet certain commitments?

Hard Work : Do you care about what you're doing and more importantly who you're doing it for? What is the quality of your work? How often do you put yourself in your client's shoes to better serve their needs?

A Great Attitude : Are you fun to work with? Do your clients dread picking up the phone or having you drop by or do they walk away with a better attitude? Do you make your clients feel ignorant when they ask questions? Do you listen to feedback well?

Mixed Priorities

I see many companies focusing on ways to differentiate themselves and ignore the fundamentals at the same time. Don't get me wrong, I think the differentiators are great, but only when they build from the fundamentals.

I'm a reasonably smart guy, and I've been around the block many times building applications using Ruby/Rails. But my experience, my network, and even my cost are all secondary to providing value through hard work and honesty. As well as being able to do it in a way that makes it a lot of fun for both my clients and myself.

I want to hear from you

What I love about this outlook is that there are no barriers to the doing the fundamentals well. They are difficult to do well, hell I'm constantly learning new ways to better apply them, but you can start immediately. Your experience, expertise and network are all built over time.

What has been your experience? I want to hear from both companies who provide their services as well as from clients who have had great and less-than-great interactions.

Nginx is extremely performant

2010-06-11T17:10:16+00:00

A couple days ago I wrote an article about perceptions I've encountered as a freelancer. The article took off on Hacker News, which a great feeling.

I received several thousand page views in the process. At first I was like "Wow!" and that quickly turned into "Oh crap..." I wasn't sure if my server hosting this blog would be able to handle that amount of traffic. But Nginx handled it like a champ.

When I setup this blog, I found an excellent How-To article on setting up Wordpress on Nginx using FastCGI from Aaron Schaefer. At the time this blog was using 5 PHP CGI processes and wasn't using any form of Wordpress page caching, however neither memory nor CPU broke a sweat. And I'm only running on a few hundred MBs.

I don't think Nginx is a perfect fit in every instance, however I'm really pleased with the results. I definitely recommend it to anyone else who is on the fence.

I am far from unemployed

2010-06-09T12:13:55+00:00

Monday was the beginning of my third week working independent. And these three weeks have been a lot of fun. Very busy, but fun. However one thing that surprised me was the reaction from others when they asked what I do for a living.

The most typical reaction I have been getting from local friends and acquaintances who are full time employees is sympathy. Phrases like "Well you gotta do what you gotta do." or "Things will turn around, the economy is improving."

No no NO!

I chose this path. I wasn't forced to go independent as a result of a layoff or the inability to find full time employment. I love what I do and I love that I am able to help other businesses who need my skills and experience.

This reminds me of a blog post a friend shared years ago, that has now been lost, which described an Entrepreneur's move from the Midwest to the West Coast. He too was taken back at the differences in reactions. Generally a Midwest-ern would say something out of pity or look at him as if he were jobless. While the people he talked to in the West Coast would get excited and share their own dreams of starting something new.

I am far from unemployed and so are the plethora of other software freelancers out there. Sure we may have downtime, but that is just one part of our world. So the next time you are talking to someone who mentions they are independent, and you feel sorry for them, mentally check yourself. If you like the guy or gal, ask for their business card and pass it to someone you think would need their services or tweet/blog about the great interaction you had with them.

I appreciate that way more than sympathetic encouragement.

Update 6/12/2010

This article took off on Hacker news and there was a lot of great feedback both for and against this post.

Big Changes. Going Independent.

2010-05-24T17:30:12+00:00

What's the news?

Starting this week, I'm putting out my shingle ... I'm going independent ... and I'm praying I won't starve.

I feel blessed with the opportunities I've encountered along my journey, and lately I have had a strong urge to strike out on my own. I want to experience what it's like to be an independent business owner, and I am excited for the opportunity to work with extremely smart developers as I continue this path.

I'm also curious if I will come to love this new freedom or if I'll hang myself with it.

But why are you leaving Elevator Up?

Elevator Up has been such a great experience. Both Aaron and Dayna are great guys and they truly care about both their employees and their clients.

One thing I really appreciate about my experience at Elevator Up has been my exposure to many different communities and business models. Even though I'm going independent, I don't feel like I'm leaving Elevator Up, but instead that I'm staying focused on the development community to which I feel the most attached.

This transition allows me to stay specialized in the my sphere while at the same time still being able to work with the gang at Elevator Up in areas where my strengths shine. It also allows me to engage with clients that may not have originally been a good fit for Elevator Up, but then allow me to bring Elevator Up into the conversation as they grow.

Aaron once said the phrase "Just because you work independent, doesn't meant you work alone" and I'm pumped that I am continuing my relationship with Elevator Up, but in just a different light.

Ok, what do you really think about Elevator Up?

Just that, Elevator Up is a great place to work and a great family. I think the people who know me best know that I'm too honest to say it any other way. And frankly, I don't have the energy to put up a false ruse.

I'm excited for this next adventure, and I'm grateful for the support of my Wife, my friends, and especially my family at Elevator Up.

If you want to talk more about my transition or have any Ruby/Rails projects feel free to read about my experience and send me an email at zach -dot- moazeni -at- gmail -dot- com.

Great perspective on incentive and value

2010-05-20T16:08:03+00:00

"Finally, I don’t think there’s much value in arguing over who has the most incentive to create good products. The point is you’ll be better off in the long-term if you delivery high-value high-quality products, regardless of whether you’re a consultancy, startup, or enterprise shop."

-- Pat Maddox on Are you punching your users in the face?

Review: Crucial Conversations

2010-05-18T01:55:08+00:00

Months ago I shared my difficulties with leading others and sharing opinions effectively with Josh Little from Bloomfire. He recommended I pick up the book Crucial Conversations and even mentioned he has had to re-read it many times over the years. It was the first book I finished on my vacation, and I am very grateful for his recommendation.

After the first few pages, I was initially put off by the number of buzzwords and new vocabulary (e.g. "shared pool of meaning"). I often get turned off with authors who would rather invent vague terminology than give clear meaning. However despite the capitalization, I felt the book provided great insight.

Some especially key take-aways for me were:

Reaffirmation to first improve myself especially since it's much easier than trying to change others.
The differences between content and context. I certainly get bogged down with specifically what someone says rather than thinking about their frame of mind. Or what they're not saying and merely hinting at.
Highlighting the connection between open dialogue and a safe environment, with steps on helping set the context in a safe way.
The differences between apologizing vs contrasting, and when apologizing is and isn't appropriate. This book helped me realize that I've used apologizing as a social crutch rather than expressing regret over a transgression.
I liked the authors opinion on attitude, and how someone else doesn't change your attitude, you ultimately control your attitude and your actions that result from it.
I think the authors did a great job emphasizing the scenarios of how conversations could be handled better. They didn't just throw out their points for their readers to interpret alone.

And for my biggest take-away: I appreciated that the book focused more on positive, open-minded dialogue and not subversive techniques to manipulate someone else. The points in the book were meant for the contentious and not for the silver-tongued. That just feels right to me.

So along with Josh, I wholeheartedly recommend this book. I feel it can help bridge communication break downs between couples and peers alike.

My Vacation Reading

2010-05-15T14:41:06+00:00

Every time I go on an extended vacation I end up ripping through a half dozen books. It's probably because of a need to catch up on long overdue reading. Though I have noticed that it mentally refreshes me much more than watching episodes of LOST).

Here was this vacation's reading list. I'm planning on writing up my summary for each of the books which were all good in their own way.

Muscle Memory

2010-04-15T01:48:01+00:00

Two years ago, I made the commitment to switch the Dvorak Layout and I think my wrists thank me. When I first started, I heard a lot of concern from others that learning Dvorak would harm their Qwerty typing. But I dismissed it as lazy FUD.

After two years, I'm admitting I was wrong.

Why do I still use Qwerty

I vastly prefer working in Dvorak, however there are plenty of scenarios when I need to work in Qwerty. Pair-programming and directly administering servers have been two recurring situations that force me to consistently finger-stutter.

What is it like?

I didn't forget Qwerty, but after working in Dvorak so long I have to take pauses when I switch. Or I'll rip through a word, only to realize I typed it in the other layout. Other annoyances pop out such as Copy/Paste, Mac Preferences (Dvorak uses the W for , which keeps closing windows), and Mac switching tabs (Dvorak uses - and + for [, and ] which keeps changing the font of Textmate/Terminal/Browsers).

A different way of explaining these finger-stutters: I like to joke around when someone asks me a VIM command. I tell them "I don't know, but my fingers do", and I typically will touch a keyboard, do the command they asked, then tell them the command.

What I've been doing to fix this

So instead of using Dvorak exclusively, then jumping into Qwerty when pairing I've resorted to picking a layout at the beginning of the day and working with it the entire day. This has helped keep my muscle memory in shape.

I still have problems when switching in and out of Dvorak and Qwerty (e.g. one hour in one layout, then the next hour in the other layout). Perhaps over time I'll be able to easily switch between the two, but I'm not there yet.

If I notice I am hammering the DELETE key, I'll open up text pad and rip though a few Panagrams. At first I used the common "The quick brown fox...", but then I realized my fingers were committing that sentence to memory. So now I'll open up a site with a list of panagrams and randomly select a few to type out.

Has learning Dvorak been worth it?

This is hard to answer, but I think so. Like I said I do vastly prefer the Dvorak layout, but I do think it's important to stay realistic that you'll have to occasionally use Qwerty. However maintaining muscle memory has been a lot more work than I originally guessed.

Harvested: A New Ruby API Wrapper

2010-04-11T18:17:02+00:00

I've used Harvest Time Tracking for well over 3 years, and they have a quality product. They have also had a published API for quite some time. The past couple weeks I've been working on Ruby API wrapper for it, and today I've pushed the first release.

Harvested

Harvested is a thin wrapper around their API based on HTTParty and HappyMapper.

You can go grab and install it through RubyGems (make sure the Gemcutter source is set):

 gem install harvested

A couple quick examples of how to use this API:

require "harvested"
harvest = Harvest.hardy_client('yoursubdomain', 'yourusername', 'userpassword', :ssl => false)

# Print out all users, clients, and projects on the account
puts "Users:"
harvest.users.all.each {|u| p u }

puts "Clients:"
harvest.clients.all.each {|c| p c }

puts "Projects:"
harvest.projects.all.each {|project| p project }

More examples are included in /examples along with the gem.

Standard Client vs Hardy Client

The guys at Harvest built a great API, but there are always dangers in writing code that depends on an API. For example, HTTP Timeouts, Occasional Bad Gateways, and Rate Limiting issues need to be accounted for.

There are two clients available in the gem, client and hardy_client. If you want to deal with the issues manually, feel free to use client otherwise hardy_client provides a friendly wrapper that retries errors and waits for rate limit resets.

Update - 4/12/2010

I started documenting the codebase, so I added a link to the rdoc.info documentation.

Reflections of an Adjunct Professor

2010-04-07T02:51:59+00:00

This past semester I had the opportunity to teach the Advanced Java course at GRCC. Teaching at the college level has been something I've wanted to experience for a while and it is also quite aligned with my values. While I was excited to start the semester, I was a bit nervous at how my first class would turn out. As the semester progressed, I kept a list of failures and successes that would help me grow as a teacher. I hope this list helps other instructors as they start their career.

Using Different Tools

One decision I made early on was that I would never use PowerPoint. I think the static nature of PowerPoint slides completely disengage students and detract from the learning experience. I was lucky to be introduced to Prezi months prior from a friend, and at the time I knew it would be a great alternative to boring slides.

For instructors that haven't created a screencast before, I strongly recommend investigating them. I used SnapXPro and Vimeo, but there are many other alternates out there.

Google Docs was a great aid in creating Labs and Surveys. Legos were excellent in illustrating concurrency, especially regarding context-switching. Omnigraffle and Apple Screen Shots were also a big boon when creating my lectures.

Time Spent Preparing for Classes

I was repeatedly warned by seasoned instructors that the first class is the hardest. But I was completely taken back at how much time I would spend preparing for lectures. The course I taught didn't have a prior curriculum, and it went against my nature just to teach directly from a textbook. Yet I spent around 5-6 hours a week just putting together the lecture and the accompanying lab.

A lot of time was spent on planning the goals of the lectures, preparing them on Prezi, creating the labs, and grading the previous week's labs. I worked hard to craft labs that didn't just evaluate whether the student understood the concept, but supplemented the learning experience from the lecture.

I approximate I've spent on average 12 hours a week to prepare for a one night-a-week course.

Going Over Prepared Material

I found early on that not going over the material you've prepared can really bite you. It helped tremendously to write the solution code to the labs before I gave them the assignments. There was always something I needed to tweak in terms of problem descriptions. Even though I consider myself a good developer, if I just put together an assignment without fleshing out a solution myself, the resulting code would become tedious and lose the original intent.

One requirement as innocuous as 'Format a collection of strings so the output results in: "string1, string2, string3 and string4."' had students spending the majority of their time in the wrong area which in turn clouded the lesson.

Oddly enough, that requirement worked well when teaching Unit Testing.

Office Hours

I think I was one of the few adjuncts who offered office hours. Working at Elevator Up I took advantage of our great space at The Factory and posted weekly office hours. Despite the Holland-to-GR commute, office hours were an excellent opportunity to have a regular checkpoint for myself to focus on the class. Every Thursday evening from 5 - 7 I knew I would be working on my class.

Some instructors mention that students don't take advantage of their office hours. I had students show up about 50% of the time. I do think that scheduling can be important though. I had a few students mention that they had another class or had to work during those hours, and for those I was very clear that I would make myself available for scheduling issues.

People Fall Asleep

I know students fall asleep in class. I even remember times when I did it. But boy is it a shock to be mid-sentence and spot one student nodding off and see another drooling. I think it took all of my willpower to stay focused on the lecture.

To other new teachers, don't take it as an insult. Evening classes in warm rooms can bring down even the most alert. And mentally prepare yourself, because I was completely taken aback.

I love Kinkos

Most college offices have great equipment for making copies of exams and syllabuses, but I sure love Kinkos. For $10, they would take a PDF from a USB thumbdrive, print and staple many copies in less than 15 minutes. I know it sounds spoiled, but $10 for saving that time was well worth it to me.

Due Dates

I might have been described as a strict teacher in the way I accepted assignments. I had a simple rule:

Full Credit was only awarded if the assignment was turned in before the next lecture started
I would accept the assignment late 1 day for Half Credit
I would not accept an assignment after 1 day late.

This does come across harsh, but I believe this stance carries it's own benefits.

It helps teach the importance of time management.
I wasn't bombarded by a slew of 3-week late assignments at the end of the semester.

Additionally, I held myself to the same standard. If I would require my students turn in assignments on time, I would hand them back on time.

That being said, I do recommend keeping a pulse on the class. There was one instance where I was flexible and extended the deadline of a project 1 week, but I awarded extra credit for the students who turned in their work by the original deadline.

Pacing Concepts

Another lesson I learned early on was pacing. My early lectures made some pretty large leaps, and while they seemed fairly logical to me it dawned on me that I needed to slow down.

That doesn't mean my students were slow, or that I went to the extreme to 'dumb down' my lectures. However there is a sweet spot between being painstakingly redundant and breezing through concepts. This is still an area that I need to work on.

Connecting with Students

After realizing that I needed to work on pacing, I stumbled upon one of the biggest take-aways for me as an instructor: Connecting with Strangers. I am leading a group of strangers that I not only want to convey new material to, but I want to connect on a level that draws at that 'Aha!' moment for each one of them. That is hard enough with an individual, let alone a classroom.

This was a very humbling experience for me and I think one area in which I learned the most from my students. Good teachers connect with their students, they don't just lecture.

Final Thoughts

I had such a great experience teaching my first semester. I'd like to thank my wife for bearing with me these past four months. Especially, so soon after our newborn. I'd also like to thank my company Elevator Up for encouraging me to explore this avenue.

I've been asked if I will teach another class. If the opportunity presents itself, I may, but I now have more respect for the amount of effort teaching requires. Regardless, I did have fun and I learned more about myself and about communicating with others.

I welcome feedback from other teachers and how their early experiences went.

Introduction to Rails Talk: GVSU Mobile Developers Group

2010-03-03T01:23:59+00:00

Here is the Prezi talk I gave to the GVSU Mobile Developer User Group.

Published via Prezi

My First Introduction to Haskell Extensions: FlexibleInstances

2009-07-27T00:28:53+00:00

I've been tinkering with Haskell lately, and I came across an odd issue. Let's say I want to create a class that takes Integers, Characters, and Strings and returns an Integer.

class Something a where
  doSomething :: a -> Integer

instance Something Integer where
  doSomething x = 1

instance Something Char where
  doSomething x = 2

instance Something [Char] where
  doSomething x = 3

Trying to load this into the interpreter (or compiling it) results in the an error on the String ([Char])

Illegal instance declaration for `Something [Char]'
  (All instance types must be of the form (T a1 ... an)
  where a1 ... an are type *variables*,
  and each type variable appears at most once in the instance head.
  Use -XFlexibleInstances if you want to disable this.)
In the instance declaration for `Something [Char]'

This cryptic message essentially means that I can't make [Char] an instance of the Something class, but I could make [a] one (a list containing any type)

instance Something [a] where
  doSomething x = 3

However that stinks because then I have to do a lot more work to differentiate between a list of characters (i.e. Strings) and a list of integers.

The error message mentions a way to disable that check, and the helpful guys at #haskell gave me a hand.

If you put this at the top of your source file:

{-# LANGUAGE FlexibleInstances #-}

you end up telling Haskell to load the extension FlexibleInstances which allows you to differentiate between lists of characters, integers, or whatever else. Which allows you to load in:

-- in file TestingTypes.hs
{-# LANGUAGE FlexibleInstances #-}

class Something a where
  doSomething :: a -> Integer

instance Something Integer where
  doSomething x = 1

instance Something Char where
  doSomething x = 2

instance Something [Char] where
  doSomething x = 3

-- in ghci:
Prelude> :l TestingTypes.hs
[1 of 1] Compiling TestingTypes     ( TestingTypes.hs, interpreted )
Ok, modules loaded: TestingTypes.
*TestingTypes> doSomething 1
1
*TestingTypes> doSomething 'c'
2
*TestingTypes> doSomething "foo"
3

Nothing ground breaking, but I thought I'd pass this tidbit along.

Not Enough Hours

2009-05-22T16:30:42+00:00

Yesterday I was in a bad mood. In my disgruntlement, I decided to do some simple math on the number of hours in a day.

My average weekday is comprised of these activities:

Sleeping ~ 8hrs
Working ~ 10hrs
Miscellaneous - 3hrs (Driving, Showering, Checking Twitter)

That math only leaves a remainder of 3 hours a day. (24 - 8 - 10 - 3 = 3)

Quick Thoughts

That's...depressing.
Less sleep could help, but probably ruin the quality of the rest of the hours.
I need to become more selective what takes up my free time. Do I really need to watch that new episode of NCIS?
I should check Twitter less

Bigger Revelation

My weekends are extremely valuable, and there's no doubt I've been using them ineffectively. If I had to guess, my typical weekend boils down to watching T.V. playing mindless games, and catching up on work. Well, not anymore.

So I hope you enjoy this upcoming Memorial Day. Whether it's to relax with the family, crack open a new book, or just have "alone time".

I know I'm planning on making it count.

Changed My Handle

2009-05-19T12:34:27+00:00

I've used the handle "zedder02" for many many years and for many different applications. It has it's own history, but I think it's time to retire it.

So now I'm known as "zmoazeni".

Contributing to RailsBridge

2009-05-17T19:17:55+00:00

Need Code Help?

I'm really excited about the possibilities around RailBridge. As a seasoned Ruby developer I will be offering code reviews on Rails and non-Rails code alike.

Steps to ask for help are pretty easy.

Create a Github Gist with the code you want to go over.
Ping either RailsBridge, or ping me through Twitter with the URL to the Gist and your contact information.
Let's chat!

Universities and Colleges in the Michigan Area

If your Computer Science department wants seasoned Ruby/Rails developers to speak with your students or wants to offer RailsBridge community support to your students. Send me an email at zach -dot- moazeni -at- gmail -dot- com, I'd love to speak with you.

Comments are back

2009-05-15T01:48:06+00:00

Well I finally got off my ass to port over the comments from Mephisto. Let me know if you find anything amiss.

New feed URL

2009-02-27T22:51:12+00:00

Looks like FeedBurner/Google ended up shuffling some things around. You may need to update your readers to using either http://simplechatter.com/feed/atom/ or http://feeds2.feedburner.com/simplechatter/.

Migrating to Wordpress

2009-02-27T22:43:03+00:00

I'm in the process of migrating from Mephisto to Wordpress. Everything should be up and running other than comments. Hopefully I'll get those wrapped up by the weekend.

Tools for Remote Collaboration

2008-12-21T22:50:15+00:00

For those of you who don't know, Janson works in Seattle while Aaron and I work in Holland MI. Even though he's in Seattle, we're still able to work as if he were in the office. We've had pretty good success with a few tools.

Skype and a good microphone

Multiple times a day we call Janson on Skype via our badass Snowball. This microphone rocks, and it's fairly inexpensive (around $100). It works so well that Janson is able to listen to the music we have playing in the office.

Janson also picked up a Snowflake which has worked great.

I always thought video was key to remote collaborating, but I've totally changed my mind. Audio is the first step. Often Janson and I will be working for over an hour via Skype and it feels like the other person is right next to you.

Writeboard

Writeboards are a 37Signals product that are like a versioned document. We use these frequently for asynchronous collaboration.

There are other alternatives to Writeboards, but we've found that their low barrier of entry and textile support has helped a lot.

Campfire

Another form of text communication we use regularly are Campfire chat rooms, another 37Signals product. These have been really helpful from pasting code snipbits, uploading shared files and privacy/guest access.

All of us at Elevator Up are very familiar with IRC, and we may switch back to it someday, but Campfire gives us all the chat room features we need without hassle.

EtherPad

Last Monday Janson came across EtherPad and oh boy it's a gem.

When collaborating on a document we've been using a combination of Writeboards/Campfire chats. They do the job, but there's a ton of "Okay, I saved. Reload." or "Hrm, I'd rephrase it this way. Lemme copy/paste" which gets rather annoying.

EtherPad on the other hand allows multiple people to be editing text at the same time. As far as I know, it's very similar to SubEthaEdit but through the browser instead of with a client. It's helped us out tremendously especially when writing user stories.

EtherPad is in a closed beta, but they are pretty quick to grant beta access. We've only been using it for a week, and already consider it a part of our remote toolset.

VPN/SSH/Screen/Vim

Both Janson and I code in Textmate, but we both came from Vim. We've toyed with using a VPN to SSH into the other's machine. Connect to a shared Screen session and code in Vim for Paired Programming. As of yet, we've only done it a couple of times, and most of our issues are related to going back into the console for development.

We were both amazed at the responsiveness with a shared session, though thinking back on it, there's very little traffic compared to other remote solutions. This is one of our rougher tools, but I wouldn't be surprised if we make this a permanent addition.

Where's VNC?

Surprisingly we don't use VNC that often. Sometimes we use it when we need to present to a client who is also remote, but that's fairly rare. We've also found using screen capturing software like SnapX Pro to do a better job when presenting remotely.

RubyConf 2008

2008-11-20T03:11:42+00:00

I was lucky enough to attend RubyConf 2008. I really enjoyed last year's conference, and I felt this year was better.

There was lots of great content, and more than handful of time slots where I wanted to attend both. I'm eagerly waiting for Confreaks to post all the talks so I could watch the ones I missed, as well as re-watch the ones I attended.

Among all the talks I attended, there were three talks that really enjoyed.

Ruby Heavy-Lifting: Lazy load it, Event it, Defer it, and then Optimize it

This was given by Ilya Grigorik of AideRSS, and was my favorite talk of the weekend. Ilya went over their experiences developing PostRank and main optimization techniques they used with Ruby.

Primarily:

Message Queues
EventMachine
Process Forking
Custom C Extensions

Ilya didn't just gloss over each point in a tutorial fashion, but instead described how they used each item and the resulting effects.

It was very refreshing to hear someone speak of their roadblocks and creative solutions to work around them. Hearing that PostRank is making around 5 million requests per day, and is spread over 100 servers is pretty inspiring.

What Every Rubyist Should Know About Threads

Jim Weirich from EdgeCase gave this talk. Now I've been interested in fairly interested in concurrency this year. Especially as we see hardware trends stalling out on speed and moving towards multiple cores. I really appreciated this talk for two reasons.

First, it shamed me. Yup, I'll admit it. As snobby as I acted about concurrency, and as much as I touted I understood deadlocking and thread safety code, Jim's talk exposed me to my ignorance, and for that I'm very grateful.

This talk may not appeal to others the same way it did to me, however for those interested in threading basics as well as virtual machine quicks this was worthwhile.

Dramatis: Actors for Ruby

Steven Parks gave a great talk about his Actor-based Concurrency library for both Ruby and Python Dramatis. Now Dramatis is rather young, but has a lot of potential. Not to mention Steven's presentation and conversation afterwards indicates he has been working in this particular field a while.

Earlier this year I played with Erlang quite a bit, and despite the syntax annoyances, the actor model was very interesting. Steven mentioned explicit vs implicit receiving, which happens to be one of the bold stances this API takes. Erlang is an explicit receive model. Which means the code has to explicitly request the next message.

An explicit receive example with Ruby:

while message = receive
  # do something with the message and then re-loop
end

An implicit receive example:

def some_method
  # this will get called when a message is sent
end

The second example doesn't look too foreign, and that's because it's not. The entire class becomes an API, and the messaging framework calls the appropriate method. When I worked with Erlang, I liked the Actor model, but I didn't like the boilerplate code that was copy-pasted for every Actor.

I don't expect everyone to prefer this type of messaging, but for me it makes the concurrency model more transparent, and the actors easier to read as well as easier to test.

That's a lot of concurrency

As you can tell all my favorite talks all had some connection with concurrency and scale. That's because I've been very interested in scaling Ruby applications. Not because I'm some outside developer who is evaluating Ruby as a language and concerned about FUD. It's because I am a Ruby developer, and I've been writing in Ruby for the past couple years, but I have rarely heard talks addressing scaling.

There were many other great talks at the conference. For those on the fence on whether to attend next year, I definitely recommend it.