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.
You can install the release candidate using npm:
- Improved Construction.
- Arbitrary Data and Methods.
- Observable Transitions
- Conditional Transitions
- Promise-based Asynchronous Transitions
- Improved Transition Lifecycle Events
- Goto State
- State History
- Webpack build system
Additional documentation is available on github in the v3 branch:
- States and Transitions
- Data and Methods
- Lifecycle Events
- Asynchronous Transitions
- Error Handling
- State History
- State Machine Factory
- improved npm install instructions.
- switch to uglify-js for building minified version.
- exclude build files from bower install (issue #75)
- ensure WILDCARD events are included in list of available transitions (issue #93)
- fix FSM getting stuck into “*” state when using double wildcard (issue #64)
- add function to return a list of all available states to help automated testing (issue #54)
- state machine hides callback exceptions (issue #62)
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?
- we’re all using e-readers?
- we’re all ordering online?
- tech books are too expensive?
- and get stale too quickly?
Perhaps… we’ve simply lost our attention span and now look for quick answers from StackExchange and Twitter.
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
_“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:
- Listen on a socket (e.g. a web server)
- Subscribe to a queue (e.g. a resque worker)
- Poll a DB job table (e.g. a DelayedJob)
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…
- the demands of our users
- the demands of our dev team
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:
- Synchronous Request/Response
- Asynchronous Worker Queue
- Asynchronous Publish/Subscribe
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.