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.
Installing
You can install the release candidate using npm:
npm install --save javascript-state-machine@3.0.0-rc.1
Highlights
- Improved Construction.
- Arbitrary Data and Methods.
- Observable Transitions
- Conditional Transitions
- Promise-based Asynchronous Transitions
- Improved Transition Lifecycle Events
- Goto State
- State History
- Visualization
- Webpack build system
Documentation
Additional documentation is available on github in the v3 branch:
Licensing
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:
- improved npm install instructions.
- switch to uglify-js for building minified version.
- fix for javascript error when running in jasmine/node (issue #88)
- 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)
The Future
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…
- 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.
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:
- 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.