Daniel Huckstep gave a great presentation on what you can do with the Ruby Standard Library, definitely worth a watch.
Last week I wrote about our experience over at AuthorityLabs and the Hollywood Hack Day and it got me thinking about the experience vs our trips to regional conferences. We typically go to a handful of regional Ruby and Mongo conferences a year and do about 1-2 hack-a-thons a year. Next year will be different. We will be attending more hack-a-thons and fewer regional conferences.
At a conference you go to a day’s worth of content which 1 or 2 sessions really excites you, the rest of the fun and information comes from the Hallway sessions and after hours drinkups/hack events. Sure you probably even write some sort of little app during those less than inspiring filler sessions.
At most hack-a-thons you can bring your team and idea already flushed out, just no existing code. While winning is always nice don’t go to win, go to bond and learn. What you will get from the event that you won’t get from a conference is working as a team towards and shared goal with a deadline and the experience of presenting to a crowd of peers.
I have learned a few other things from attending these hack events. If you are going to experiment with a new technology take some time before hand to get familiar with it, don’t let it be what keeps you from benig able to produce a working prototype. Also make sure your idea is modular and don’t be afraid to change direction once you start. Grand ideas are exciting but remember your timeframe. If you take a big idea make sure it is broken down into smaller deliverables this way if you don’t finish the whole thing you will still have something to deliver and show at the end of the event.
If you are like most developers I know, writing code is fun! Creating new apps and solving problems is fun! And learning something by actually doing it works best and is fun! So here is my proposal to you. Instead of going to that next conference find a hack-a-thon and take your team.
My rating: 5 of 5 stars
Well written book that is stuffed with seemingly useless data until the author ties it altogether. The Guardian has always been at the forefront of data journalism and this book gives some insight to why that is. Quick read that is a must for any data junkie.
My rating: 3 of 5 stars
Great introduction into Personal Kanban and even Kanban in general. The author does a wonderful job walking you the history of Kanban and the strengths it has for your personal workflow. Even those that have never experienced Kanban can have a board up and running by the end of the book.
My rating: 3 of 5 stars
Very quick read but the content was light and not that satisfying. Some decent high level stuff on the “Drive Train Approach” but overall I would only pick this up if you are looking for a quick read while your kids are playing at the park.
Recently I wrote my first article for a publication. What an experience that was. Writing on a blog almost no one reads has much less pressure than writing for a magazine that actual has a readership. The article itself was relatively easy but I learned my fair share for the editing process, which I need to write up later. In the mean time, here is the link to my article.
This was a great book for those looking to get their feet wet with MongoDB. PHP And MongoDB covered many more topics than many of the MongoDB books I have read recently and while I am not a PHP developer gave me a few more ways to leverage MongoDB in my day to day work.
I especially enjoyed the chapters on Geospatial functionality and the GridFS system. Both of these topics we handled throughly and are typically glossed over in other books.
The one place I felt this book was light was the operations and administration side of things. Nowadays, many developers are handling operations as well and I feel that those topics could be explored further in books like this.
All in all, I would recommend anyone in web development looking for somewhere to start with MongoDB pick up this book and give it a read.
View all my reviews
Seven Databases in Seven Weeks is a great book for giving you an overview of the latest databases in the different segments out there. It is definitely an entry level chapter on each system that will let you know whether or not to pursue it further with more in depth material.
Anyone curious about what is available besides the de facto SQL standard offerings should give this book a read.
View all my reviews
Your metrics are showing a decrease in performance and users are starting to complain. You start digging through the performance metrics, source code and your stack to find inefficiencies and places you can gain that performance back. What if you do not find any low hanging fruit and solutions are going to be invasive, complicated and time consuming? While those things may need to be done, do not just dive in and start the surgery, stop and ask who am I doing this for?
Humans are driven by numbers. Why do you think there are some many top 10 lists, 5 easy steps to be a guru, etc? Most developers just start attacking the problem with the goal being to get those numbers back in an acceptable range. Maybe they through up some caching, rewrite some queries or upgrade a server. Ultimately they get the numbers back into that arbitrary acceptable range, wrote some fancy code and might have wasted their time.
Yes, I said wasted their time. We need to step back and look at more than the performance numbers. Look at the analytics for your app. What does the actual user usage look like? How does that data looked when overlaid on your performance metrics? Look for the patterns and correlation of the datasets. The insight you gain might surprise you and point you to where the real problem lies. If you find a rarely used feature(s) seriously consider removing them. You may be surprised how one such feature can bottleneck the system.
Removing a feature that is causing a table lock or extreme CPU spikes can free up those resources allowing the rest of the site to flow and with the usage data you can assess how valuable that feature really is. If you can’t decide one way or the other, ask your users. At the end of the day you may need that feature but your users can live without it for increased performance while you work on a better long term solution.
Don’t be afraid of throwing that hard work in trash. While it may seem like your app is moving backwards what you are really doing is improving your user experience, code and performance maintainability and doing so with the right combination of data to back up this decision.
In my last post on Application Deployment I talked about deploying your application straight to production and using metrics to measure it. One of the tools we us is Scout for server monitoring. Scout is a great service that not only monitors you typical system metrics but has a great collection of community built plugins and the capability to write your own plugins (using Ruby).
It has all of your standard features, Graphing, Triggers, Email and SMS alerts, Server Groups, support for cloud instances, etc. But what we really like is the ability to build your own dashboard as well as custom graphs.
We have charts that we built and use on our main monitoring board. These charts combine our Redis Queues, Processing Throughputs and Database Commands. The great part is that all of the data points come from different servers and services that on their own don’t really give enough insight into whether or not there is an actual issue or where that issue maybe. But when they are all combined on to one chart the context for spikes can be seen and appropriate action (if necessary) can be taken.
Scout was the first monitoring service AuthorityLabs began using back when it was a one server web app with a handful of clients. It has served us well since then growing with us and they are continuing to add items and make the app more robust. We have since supplemented our monitoring with other services and internal tools but Scout is still a go to for us when it comes to building a custom plugin and getting those data points on a graph with our existing metrics.
Next time I will cover how we used New Relic to help us with performance monitoring and application bottlenecks.