Last night I had the pleasure of presenting to the Boston Ruby User’s Group on CoffeeScript. My talk was geared to helping Rubyists understand, and hopefully love, CoffeeScript. Along the way I tried to debunk a few myths and preconceptions as to what CoffeeScript is and isn’t. The reaction was really positive, so hopefully I did my job. Anyway, here are the slides: http://www.slideshare.net/markykang/coffeescript-bostonrb-892011 Enjoy!
I have to ask a question to my fellow Rubyists out there? Why are you still using YAML? I know why you think you like YAML. You think it’s a great way to write configuration files, but it’s really not. You know what’s a great way of writing configuration files for Ruby apps? RUBY! I know it’s crazy, isn’t it? But why not? Why would you not want to use Ruby for configuring your applications instead of YAML?
UPDATE: Unfortunately TweetKO is no longer available. Sorry about that. Twitter is an incredibly rich source of information. I find out about new libraries, applications, plugins, screen casts, etc… But, there’s a problem with is overwhelming amount of information… keeping track of it all. A lot of time I read Twitter when I’m on my phone. I’ll see a link to an article or website, etc… but I don’t have time to read it then, what do I do?
About six weeks ago I announced FluxTracker.com a unified issue, document, and error management service. The response has been amazing. People love that you can now manage all of those things in one place, without any configuration. Well, today I’m happy to announce that FluxTracker has taken the next step forward to make managing all aspects of your project easier. Introducing FluxTracker Feedback. FluxTracker Feedback allows you to put a little feedback widget on your site that can be used to collect information from your users, such as feature requests, support requests, and general comments.
Because I maintain several open source projects on Github I’m constantly getting emailed questions or issues, or people are always opening up tickets with bugs, issues, complaints, etc… And I really appreciate the feedback on these projects, I really do. What I would appreciate more is if instead of just opening a ticket, or sending an email, why not fork the project, fix it, and then contact me? Now, I know that sounds like a lot of work, but honestly it’s really not.
UPDATE: Unfortunately FluxTracker is no longer available. Sorry about that. For the last few years every project or company I’ve worked for has started the same way, by setting up Basecamp, Lighthouse and Hoptoad (or similar ones anyway). Why? Basecamp - so we could share documents and todos. Lighthouse - so we could track our issues and bugs. Hoptoad - so we could track the errors our application was generating.
«Testing is painful.» «Testing is hard.» «Testing is complicated.» «Testing is not fun.» I hear those sorts of things all the time when I talk to people about testing. I agree that sometimes testing can be all of those things, but if you choose the right tools, the tools that best suite you, testing doesn’t have to be. Let me give you an example of what I’m talking about, how choosing the right tools can make a huge impact on how you feel about testing.
So back in the dark ages of my career, pre-2006, I spent a long time coding Java. Yeah, I know, please don’t judge. Anyway, In Java, for those of you who are unaware were two constructs that I occasionally wish I had in Ruby, those are Interfaces and Abstract Classes. The difference between these two constructs is subtle, but important. In Java an Interface is a basically a blueprint of methods that the class who implements the Interface needs to implement.
Last week I received an email from someone who used to work at a company that I used to work with. I didn’t know him, but he knew me through my work at the company, and my other exploits. He sent me an email to say that after a short time with the company he had been laid off, along with half of the development team. He wasn’t looking for pity, but rather advice.