Rapid web development with MongoDB, Express, AngularJS, and Node.js
Problem 1: Prototyping, or, how do I build the damn thing?
With the growing popularity of the lean startup model, the pressure to shorten product development cycles and churn out a prototype application quickly and cheaply has never been greater. And, as developers, we’re doing this better at an exponential rate. Projects that once required hundreds of millions of dollars of capital in the late ‘90s became projects that you could build in a month or two with a couple tens of thousands of capital at a startup accelerator around 2008. Now, these sorts of projects are being churned out at hackathons around the country in a matter of days. As great as this seems, we can do better.
Over time, crypto-currency networks such as bitcoin will get stronger
If a crook gets access to the credit card or wire transfer networks, it’s a disaster. That’s because, as I explained in my recent article about security models, these traditional financial networks achieve trust by excluding bad actors through access control. Effective access control requires exclusivity and strict vetting, only a small carefully vetted group of “trusted actors” are granted control.
Bitcoin and other crypto-currencies based on the blockchain invention are different. Trust is based on computation, not access control. On the bitcoin network you trust math so everyone can have access. That also means that there will be bad actors, arguably just as there are on access control networks, and nuisance attacks. Fortunately, these types of attacks cannot affect the distributed asset ledger, the blockchain, because to achieve the level of trust to write into the ledger you must apply enormous distributed computation. The root of trust is in the majority of computing power, not individual actors or any central authority.
Part One: Easily find Chromecast devices on your local network
Now that Google has opened up the Chromecast API for anyone to play with, it’s possibile to create iOS applications that can leverage the $35 device as a way to display to HDMI devices wirelessly. In this series of tutorials, we’ll go over the API, starting with configuring your project to use the framework, and finding devices out on your local network to play with.
Let’s assume you’ve set up a Chromecast device attached to an HDMI TV and have it configured for your local network. Now it’s time to get an App set up to use it. We’ll use the iPhone Simulator in these examples, since it can talk to Chromecast devices just like a physical device, as long as the Mac you are developing on is on the same LAN as the Chromecast dongle.
Begin by creating a project, as usual. For this example, I used a single-view Storyboarded app. I set up an
UITableView inside the default
UIView, hooking it’s datasource and delegate to the default view controller the wizard had created. Next, I went to the Google Google Cast API page and downloaded the iOS framework, then used the “Add Files…” project option to add the framework to the project, copying in the files.
Definitive answers require further testing
The following is from the second issue of BioCoder, the quarterly newsletter for synthetic biologists, DIY biologists, neurobiologists, and more. Download your free copy today.
Within DIYbio, one cannot escape the hacking metaphor. The metaphor is ubiquitous and, to a point, useful. The term connotes both productive play with an existing technology aimed at improvement and, at the same time, play with sinister undertones. In this sense, hacking captures the promise and pitfalls of the dual uses any mature technology might be put to, whether that technology is as dramatic as nuclear power/weapons or as mundane as a free/premium software license. But every metaphor has its limits. Pushed too far, metaphors break down, and instead of illuminating, they obscure. Which brings me to ask: how far can the hacking metaphor be pushed within DIYbio—at least the part of DIYbio falling in line with synthetic biology?
Building functionality that really delivers the expected customer value
By now, many of us are aware of the wide adoption of continuous delivery within companies that treat software development as a strategic capability that provides competitive advantage. Amazon is on record as making changes to production every 11.6 seconds on average in May of 2011. Facebook releases to production twice a day. Many Google services see releases multiple times a week, and almost everything in Google is developed on mainline. Still, many managers and executives remain unconvinced as to the benefits, and would like to know more about the economic drivers behind CD.
First, let’s define continuous delivery. Martin Fowler provides a comprehensive definition on his website, but here’s my one sentence version: Continuous delivery is a set of principles and practices to reduce the cost, time, and risk of delivering incremental changes to users.
A common vision is more important than seeking approval
Bruce Eckel is well known for his books in the field of programming, such as Thinking in Java, Thinking in C++, and Atomic Scala as well as his co-leadership of the Java Posse. And yet, on top of his work in programming, he has spent the last several years investing in and researching a topic that seems quite different, yet is intertwined with the destiny of software companies: the culture and operation of businesses.
In his OSCON 2013 Mainstage session, Bruce lays the foundation of modern business management, including a look back as far as Taylorism, a survey of what it means to get an MBA, and ways to gain this knowledge outside of the traditional institutions.
Reinvigorate a Perl project today
I contribute heavily in the Perl community, and I’m consistently impressed by the pains we take with code and assets that we personally have no interest in. There’s a group of Perl people who shepherd (camelherd?) code and projects that have lost their maintainers. I’m one of those people.
There’s a very simple system CPAN uses and which has been working since around 1994. Basically, CPAN is a big directory structure that other mirrors rsync (see Jarkko Hietaniemi’s The Zen of Comprehensive Archive Networks). People contribute code through the Perl Authors Upload Server (PAUSE), which does some light verification for identity and permission for the namespaces in that code. No one really “owns” a namespace in Perl, but developers have permissions to control it, including extending that permission to other developers. This is a small bit of a social control. (As an aside, Perl 6′s design handles this differently by allowing people to specify an “authority” for modules)
An excerpt from the third edition of PHP Cookbook
Editor’s Note: The following excerpt is from the third edition of PHP Cookbook by David Sklar and Adam Trachtenberg. For those already familiar with PHP, PHP Cookbook shows you how to overcome specific problems in your everyday work. Programmers coming from other languages will also find recipes helpful which demonstrate how to accomplish a particular task in PHP, such as sending email or parsing JSON, that you may already know how to do in another language. The recipes are self-contained in a simple problem-solution-discussion format with explanations of how and why the code works the way it does.
This cookbook arms PHP developers with important information for key PHP updates, particularly data manipulation, web services, internationalization, database access, security, and testing. This excerpt, from the chapter focused on Web Fundamentals, demonstrates how to set the HTTP Status Code and how to redirect a user to a different web page than the one they requested. Portions of this chapter have been edited and condensed for the purposes of this excerpt.
Disposable robot assassins and spreadsheets
Computers aren’t ready to write much of our code for us, but they can still help us clean and improve our code.
Bowkett explored many options and iterations of his automation ideas,
- The roots: Martin Fowler’s classic Refactoring. [at 00:50]
- “Probably the first time ever you see a developer or hacker enthusiastic about using a spreadsheet… I am that fluke.” [at 01:48]
- Matching method names with the ack and wc Unix command line utilities, and finding some useless methods. [at 5:58]
- “More complex information… surfacing an implicit object model.” [at 7:45]
- Filter scripts and text streams [at 14:45]
- “Towlie, because it liked to make things DRY”, using similarity detection in Ruby. [at 16:37]
- Building on JSLint [at 20:10]
- “Have script that… tells you this file is the one that people have edited most frequently. [at 30:29]
- Grepping through git history [at 32:53]
- “Automatic refactoring will let you get to better code much faster.” [at 36:25]
It’s an amazing mix of capabilities that let you build your own robot (code) assassins.
Nobody's perfect, and neither is your code, but that's OK
I discussed one thing that developers hate last time around — commenting — so I thought I’d follow up with another big source of developer frustration: Debugging.
Bugs happen. Every developer in the history of programming has had to debug, even the legendary ones who write code with butterflies. Becoming a skilled programmer doesn’t mean never making errors, it means becoming better at finding and fixing errors. When you’re starting out, your programs will likely be small enough that you may be able to figure out the problem by taking a closer look at your code, paying attention to the syntax, and tracing the execution process in your head. Once you get beyond that initial stage, though, you’ll need some help to find the bugs.