Welcome, I'm Jake Gordon, a full stack developer who builds web and mobile applications for SaaS companies, and occasionally makes fun games on the side.
Earlier this year, the javascript-state-machine libary underwent a major rewrite for version 3.0 in order to support more advanced use cases - as well as tidy up some of the existing ones. It has been available as a pre-release candidate for the last few months and has now been formally released as v3.0.1
The javascript-state-machine library is having a major rewrite for version 3.0 in order to support more advanced use cases - as well as tidy up some of the existing ones. It is now available as a pre-release candidate for early adopters.
You can install the release candidate using npm:
npm install --save javascript-state-machine@3.0.0-rc.1
Additional documentation is available on github in the v3 branch:
Please note that v3.0 is dual licensed under LGPLv3 for open source projects, while a commercial license is also available.
My javascript-state-machine library has been in hibernation for a little while - as have I - but we sleep no more! Starting with a small point release - 2.4 - to clean up a few loose ends:
In my last post I delved into a big list of things you probably have to think about if you’re starting a SaaS company.
I wanted to also take a moment to recognize the growing number of 3rd party SaaS vendors we depend on in order to build out our own platform, and the increasing amount of time we must spend on evaluating and integrating all of these pieces into a (hopefully) cohesive whole.
Generally speaking, for a lean startup we should be spending our resources on the core product features that are central to solving our particular business problem. I should not be spending time on peripheral concerns that would be best outsourced to a company that has already solved those particular issues.
I want to Build only if it’s core to the problem at hand, and Buy if it is secondary scaffolding that I just happen to need in order to support my core feature set.
What this means is that a large part of a tech co-founders role is making lists like this one…
In 2015 I plan to (co)-found a new software startup company.
While I am confident about the technical aspects, I am less sure about the business, sales, and marketing components. So it will be critical to have co-founders with complementary skills in those areas.
Of course, having great co-founders doesn’t divest me of the responsibility to understand those areas. So recently I started to make a list of all of the things that a software startup must think about, make decisions upon, and act on, in order to succeed.
Naturally, being a developer, my list started with the technology - the services we would need, the platform we would choose, the development process we would implement, the infrastructure we would put in place…
My list grew long
Then I started to think outside of my area of expertise, and consider the bigger picture, customer validation, market research, competitive analysis, branding, funding, legal, accounting…
My list grew much longer
I am a natural organizer, so once I have a long list I want to categorize and organize it, and the obvious starting point was to break it down into the classic startup co-founder roles…
Yesterday, I sent out a survey to developers asking if they still own and purchase technical books, along with a number of questions related to lending and borrowing books.
Huge THANKYOU to all who responded, and to the various tech groups that allowed me to post my request.
I’m considering resurrecting an old side-project of mine that would provide a local community book lending/exchange/selling platform - not a business, just a side-project, but I thought it important to find out if developers still used physical books, or if we had all switched to e-readers, or simply abandoned books for the quick fix from StackExchange (I hope not).
The survey was rough, biased, and not scientific, but I found the results interesting and wanted to share.
The nuances of human decisions can never really be summed up in a simple yes/no question so the open ended comments at the end are particularly interesting.
Here are the survey results from the first 100 respondents:
I love books, especially technical books, and while there is no substitute for getting your hands dirty and to learn by doing, it can be refreshing to step back out of the weeds to get a holistic overview of a topic from a well written technical book.
But am I alone?
The audience for technical books seems like a shrinking market. There are very few technical bookstores left, and the computer section in Powell’s seems to shrink every time I visit.
Perhaps…
Perhaps… we’ve simply lost our attention span and now look for quick answers from StackExchange and Twitter.
I was inspired by a talk from @jasonrclark at this weeks @pdxruby that reminded us that the Shoes project is still alive and well. I had a little free time so I thought I’d make a tiny contribution and take a day to port over one of my simpler javascript games to Shoes.
Shoes was is a cross-platform Ruby desktop GUI framework aimed at beginners wanting
to get into programming. For those of us who have been in the Ruby community for a while we might
have assumed that Shoes died when _why left the community. However, from the
shoesrb.com history…
_“Way way back in the day, there was a guy named _why. He created a project known as Hackety Hack to teach programming to everyone. In order to reach all corners of the earth, _why decided to make Hackety Hack work on Windows, Mac OS X, and Linux. This was a lot of work, and so _why decided to share his toolkit with the world. Thus, Shoes was born. Everybody loved Shoes. Many apps were made, and put into The Shoebox, which no longer exists. But, one day, why left. In his memory, Team Shoes assembled, and carried on making Shoes. They released Shoes 3 in late summer 2010.”
… and they are actively working on Shoes4.
So here’s a version of Tetris you can run with Ruby Shoes:
Your application might need a long running process in order to:
Much of the time you will use an appropriate 3rd party server such as Unicorn, Resque, or RackRabbit, but sometimes you just want to write some Ruby code and make it daemonizable. To achieve this you might reach for gems such as Dante or Daemon-kit, and these are good options, but with a little work you can avoid the additional gem dependency and get a deeper appreciation for the underlying Unix process mechanisms along the way.
As part of my work on the RackRabbit server I had to learn a little more about daemonizing and forking unix processes, and so I wrote up a little how-to for those of you who might want to daemonize your own Ruby code without adding any new dependencies.
In this series we have discussed:
We talked about why we might implement a Service Oriented Architecture in order to scale to meet…
We also talked a little bit of theory on what an SOA looks like, how to define the boundaries for our services, the practical implications of building a distributed system, and the 3 main communication patterns of a distributed system:
When implementing SOA using HTTP, we discovered that we have access to a robust set of technical options such as Rack, Unicorn, HTTParty, Faraday, Redis, Resque, or Beanstalkd, but no single technology can provide for all 3 communication patterns.
When implementing SOA using AMQP, we discovered that we can implement all 3 patterns using a single technology, but the implementation details are a little more tricky, programming directly to the AMQP interface, and the infrastructure and community support for hosting production-ready consumers are lacking (e.g. there is no easy-to-program-to Rack interface, or Unicorn style server for easily load balancing RabbitMQ consumer processes).
Just like everything in our profession, there are trade-offs.