Citing a desire to work on research projects after three years of focused work, Node.js creator and project leader Ryan Dahl sent out a message today that he will be “ceding
my position as gatekeeper to Isaac Schlueter”. He stated:
I am still an employee at Joyent and will advise from the sidelines but I won’t be involved in the day-to-day bug fixes. Isaac has final say over what makes it into the releases. Appeals for new features, changes, and bug fixes should now be directed at him.
Kudos to Ryan for creating Node.js and then taking it as far as he has. I can completely understand how after three years of rather intense work he wants and needs to pursue a different path. His departure is also a huge statement about the power of the Node.js community – and also of Joyent as a sponsor and employer of so many key Node.js developers – to continue the development of the language without the creator at the helm.
As just a random developer out there using Node.js, I certainly thank Ryan for all he’s done and wish him all the best in his new role!
To install the package, assuming you have pip installed, you should be able to just type:
pip install tropo-webapi-python
and then you can get started building Tropo applications that use voice, SMS, IM or Twitter as channels to communicate with people. The documentation for the Tropo WebAPI provides a full explanation of the API and also sample applications. Samples are also provided in the distribution.
The “tropo-webapi-python” package lives on Github at:
and those of you wanting to live on the edge can simply clone the repository from Github and use it there.
I’ll also mention that at this point I’ve completely stepped away from the maintenance of this ‘tropo-webapi-python’ package (as I’m no longer with Voxeo) and Justin and the Voxeo Labs team are now maintaining the package.
Have fun with it! I definitely enjoy creating Tropo apps using python!
I’ve been using Unix myself in various forms since the mid-1980′s. Much of my time was, of course, spent in the land of Linux… but even now I’m writing this post on an operating system that evolved out of that early Unix work (Mac OS X).
It is very hard to understate the role that Unix has played in our technology history… and this post provides some nice stories from those early days.
Well worth a read… (I say while stroking my beard that is now definitely grey…
What does Amazon.com do so much better than Google? And why does Amazon do everything “wrong” while Google does everything “right”… yet offer a better platform? How should you construct a “platform” so that everyone can use it?
If you are a developer, IT manager, product manager, system architect, product marketer, CTO or even a CEO, you really need to take a bit to read this “Mother of all Reply-All failures” that was written by Googler Steve Yegge and accidentally posted publicly back on October 12th. Steve pulled down his own posting of the rant, but it was re-posted to Google+ by Rip Rowan and also posted over to Hacker News. The long rant – and the comments on both sites – are worth a read:
Amazing to read via Ars Technica that Vim is 20 years old today! In the proverbial “vi vs emacs” religious war, I’ve always come down firmly on the side of vi/vim…. but mainly because I started using vi 25+ years ago back in the mid-1980s when vi represented a quantum leap forward from “ed” and “ex”!
I climbed the steep learning curve for vi/vim many years ago, wrote my .vimrc macros and continue to use it extensively even today. Of course, today on my Mac and Linux systems I’m using vim vs. actual “vi”.
Yes, his post is about Apple’s iOS, but I’m unfortunately rather confident that the results would be similar if someone were to do a similar analysis with a proxy server on apps on Android, Blackberry, Windows Phone 7, WebOS and any other mobile platform.
These are application design problems.
As programmers, we all take “short cuts” from time to time… I’m as guilty of that as anyone… but sometimes those shortcuts have grave consequences.
Mobile developers need to read Troy’s piece… and then look at their own apps and see how they can change. Actions like:
Securing the transport of login credentials! (DUH!!!)
Not stuffing giant images down onto mobile devices when those images are going to be restyled in HTML to be tiny.
Being wary about what info is gathered by apps – and also disclosing that to customers (and perhaps offering a way to opt out).
The list can go on… Troy’s article has other ideas in it, too… but the point is that in the rush to get a mobile app out there, some of these security and privacy issues (and bandwidth costs!) really do need some attention!
For those of us of a certain age, “The C Programming Language“, written by Brian W. Kernighan and Dennis M. Ritchie, was our “bible” as we learned to program in those very early days. Our copies of “K&R“, as many of us referred to it, got quite dog-eared and marked up as we used it to figure out this whole new world of “C”. It was an exciting time and a critical book to have.
Many of us, in fact, probably still have that book… the image accompanying this post is my copy that I pulled off of a bookshelf a few moments ago.
While many of us stopped programming in C years ago (although many still do), it was the language that got many of us started in “serious” work… and also that formed the background of UNIX as well.
On that note, I had quite honestly forgotten over the years Dennis Ritchie’s role in the creation of UNIX, but as has been noted in many articles today it was he and Ken Thompson that started it all. Here’s a great video from the Bell Labs days showing both Thompson and Ritchie:
Remember perl? The “scripting language” that was the one of the first that many of us used on UNIX to automate system administration tasks? And then was later used in the 1990s for a ton of web CGI programming and so much more? And that we could have so much fun with created “obfuscated” programs that looked like gobbledegook but actually did something useful?
The slide set from Jesse Vincent embedded in the RWW article is interesting in that it does show the good amount of work being done by the perl faithful to bring more stability and progress to the perl language.
I commend them all for the work… it looks like really good things are happening. Is it enough to make me personally return to working with perl? Probably not, to be honest… but for the sake of all those people who still work with perl… and for people looking for a great multi-purpose programming language with deep roots and a huge base of documentation and usage… it’s good to see the language evolving again!