Monday, March 23, 2015
Officials at Node.js steward Joyent and at Strongloop, which is involved in Node.js development, provided InfoWorld details about the upcoming release, for which thedownload should become available today.
Version 0.12 will feature round-robin clustering, providing for better distribution of Node.js across processor cores. It also will have performance optimizations including reduced garbage-collector strain. Profiling APIs in 0.12 improve memory management. Users also can run multiple instances in a single process via a multicontext capability. Clustered apps can be debugged with the Node-Inspector capability. Also supported is execSync, a synchronous API for child processes. There are also improvements in the TLS (Transport Layer Security) function.
Although the Node community at large might breathe a collective sigh of relief that version 0.12 is finally here, frustration with the pace of upgrades to the platform was a principal reason for the recent forking of Node.js, via the io.js fork. Strongloop's Bert Belder, who is deeply involved in both the development of Node.js as well as io.js, said he still expects to be working on both projects. Io.js went to a beta release last month. It features capabilities now being fitted into Node.js 0.12, such as round-robin clustering and virtual machine improvements, Belder said.
A founder of API server vendor Strongloop, Belder is a Node core contributor and a member of the io.js technical committee. He said he anticipates a reconciliation between the two factions at some point, hopefully within a half year. Right now, there are two versions of Node.js (also called Node), thanks to the io.js fork. "I think it's wasteful to have to have two projects," Belder said. Io.js proponents "really took that position that we wanted to release really frequently."
Beyond version 0.12, the focus for Node.js will be on reconciliation in the Node.js community and improving the governance model, Belder said. Fontaine said discussions about an eventual 1.0 release of Node.js are expected to happen at the Node Summit conference in San Francisco next week.
Although proponents see Node.js as production-ready now, the 1.0 release would have to ensure that no APIs are broken, and to do that APIs that need to change have to be identified first, Fontaine said. "[Version] 1.0 is an important step, and it means that we will be supporting these APIs in perpetuity."
This story, "Two years in the making, Node.js upgrade arrives" was originally published by InfoWorld.
at 11:28:00 AM
Deciding to go it alone as an independent software developer is a liberating experience. The thrill of being your own boss cannot be denied -- neither can the fact that being your own boss means building a business. It’s no longer simply about the code. Everything is your responsibility, from paperwork to partnerships, and with this increasing burden come greater pitfalls that can sink your business.
While one little mistake might not tank your independent software business immediately, such missteps tend to accumulate. It’s easy to get lost in your code, thinking everything is fine; suddenly, a pack of problems pounce from the shadows to tear your business to shreds.
Then it’s back to the résumé heap, hoping to get hired as a full-time employee again.
Here are 14 mistakes independent developers too often make in going it alone -- and how to avoid them. Good luck!
Indie dev mistake No. 1: Coding yourself out of business
High-quality code is vital to independent developer success, but heads-down coding is a job, not a business.
To be certain, you should always be thorough, with an eye toward delivering the best code you can. But make sure you have something else in the pipeline to work on when you’re done.
When coding, it’s all too easy to focus only on the work in front of you. In fact, it’s far more efficient to devote yourself to coding than it is to task-switch between development, marketing, sales, planning, administration, and so on. But that’s exactly what you will have to do to succeed. Billable work pays the bills, but finding more work keeps your business afloat.
Indie dev mistake No. 2: Forgetting that you are your brand
You may not realize it starting out, but even if you are working solo as an outside contractor with only one client, you have a brand, and that brand is you. Remember: A brand is a promise of quality and consistency, and though it can stand for whatever you think is important as a developer, it must be precise.
How you present yourself, your work, your team, and your development philosophy is the bedrock of your brand, and it should be reflected in all facets of your business, from your website to your business card to how you discuss your work with a casual acquaintance on a day off. If you are vague or inconsistent, your business will suffer.
Too often, independent software developers define their business by a tool or fad. Brands built around tools quickly become commodities -- would you rather hire a “Java shop” or an “expert in enterprise applications systems development”? Brands built around the latest trends can be lucrative, temporarily, but they too quickly become commodities.
The more specific you can be about your work and what you stand for, the easier it is to distinguish yourself from others, and the easier it is to identify and locate potential clients. More important, establishing a clear brand makes it easier for potential clients to identify and locate you.
Indie dev mistake No. 3: Trying to be everything to everybody
Customer satisfaction is essential to your success as an independent developer, but trying to please everybody can sink your business quickly. It causes you to spread your resources too thin, in the end pleasing no one.
This doesn’t mean you shouldn’t go the extra mile to serve clients to the best of your ability, or never take on work outside of your comfort zone. But pay attention to the limits of your abilities and resources. Overcommitting or signing up for work you can’t complete to the level your customers expect can quickly poison your business.
Instead, be diligent about logging your work, so you can be accurate in estimating your bandwidth when special requests arise. Increment your experimentation into new areas rather than promise to deliver big, merely because you know you can learn new tools quickly. Remember -- you have a business to run, and mastering tech to the level of your brand takes time away from paying work.
Indie dev mistake No. 4: Targeting the wrong market
Small businesses struggling to grow out of manual systems may seem like the ideal client for your fledgling independent software business; after all, they stand to reap the greatest benefits from automation. But they can also be the least trusting of technology and outsiders, and their cash flow may not be consistent enough to afford your services.
Targeting the “right” market is more art than science, but one vastly oversimplified maxim is to seek a combination of fit, finance, and fearlessness. Finding the best fit for your services is a complex, volatile process of ambitions, problems, needs, skills, gaps, benefits, and timing. There is likely to be no external signals for these, so you have to talk to a lot of people in various industries and organizations to find out. As you are doing this, you can assess the financial issue -- if an industry or organization can’t afford your services, the whole process is pointless.
Gauging “fearlessness” is more of a gut instinct. Do the players in your targeted market have the organizational courage to see your partnership through? Software systems change business operations; for many industries, and many organizations, change is scary. Don’t get lost chasing timid leads.
Indie dev mistake No. 5: Failing to identify the true project "champion"
Every software project has a “champion” (or “patron” if you prefer). This is the person with the authority to write the checks to pay for your work and the will to defend your project internally to ensure it succeeds. It is essential to identify this person and cultivate a meaningful relationship, where possible.
All too often the champion is not present, revealed, or even mentioned in consultative meetings. Worse, department heads or senior executives often insist they have the authority and budget to get the project done, when in fact that is not the case.
Always look at who signs the checks. In some companies, department managers have discretionary budgets and are indeed the champion of their projects. In other companies, executives higher up the chain -- sometimes more than one -- are the true, hidden champions; their approval is required for project expenditures.
It’s not unusual, especially in smaller, privately held businesses, for the company president to be presented as the project champion, but in reality the CFO or company owner has to sign the checks. Don’t be fooled into thinking you have a stronger commitment than you actually have.
Indie dev mistake No. 6: Failing to establish (and maintain) a sales pipeline
Selling custom software development is a slow, consultative process. Prospects may know they have a problem, but they may not be sure they really want to solve it. After all, the decision to adopt a custom solution can change the direction and foundation of an entire business; the bigger the business, the longer it takes to decide and turn. Even highly qualified, eager referrals from happy clients can take several months to close.
This means you must always add prospects to your sales pipeline. You must also always measure time spent and results. These numbers are crucial to keeping your pipeline flowing.
Suppose you need one client to support your business for half a year, and you can close one sale in six months for every 600 prospects you encounter. In this simplistic example, fewer than 100 prospects entering your pipeline every month could mean trouble.
In reality, the numbers are more complicated, but the structure of the pipeline remains the same: prospects in, time elapsed, sales out. Always be tracking time to qualify, time to close, average deal size, and close percentages. Use these numbers to project future income from the current pipeline. Subtract future costs and allow for projects (and income) ending. This will give you a leading indicator: If the resulting number is negative or trending downward, you are at risk of insufficient cash flow unless you add more clients to the pipeline.
Indie dev mistake No. 7: Failing to diversify your client base
Most independent software developers get their start with one main client. This can be a great way to strike out on your own, but beware attempting to maintain a business this way. When that one client has a hiccup, you’ll be scrambling -- or out of business.
The other downside of having one main client is that they may start thinking of you as “staff augmentation” instead of “valued business partner,” with demands going up and respect going down simultaneously. Three medium clients are better than one large one. Twenty small clients may be better still, as it is highly unlikely that a majority of them will suddenly stop at once.
Think of it this way: One client is a job; multiple clients, with diverse revenue streams, comprise a business.
Indie dev mistake No. 8: Failing to account for taxes and overhead
Most ISVs are LLCs or S-Corps, both of which are “pass-through” companies in the United States. This means you have to account for and pay estimated taxes as you go, and usually even more at the end of the year; nothing is deducted for you. Even if you pay yourself a salary, your finances can still get complicated and surprising at the end of the year. A good CPA can help, but it takes consistent financial discipline to stay current.
Nothing can sink your business like inattention to taxes.
Indie dev mistake No. 9: Playing fast and loose with collections and cash flow
Most independent development shops run “lean,” as in “very little cash buffer to fall back on.” This can turn a minor payment issue into a layoff-inducing company crisis.
The fact is, clients don’t always pay on time; this is normal, and it helps the relationship to be flexible. But if you notice a pattern -- unexplained delays, administrative misplacement of invoices, waiting on someone to sign checks, and so on -- the client may be having internal problems they aren’t telling you about.
This may be a temporary issue, but it could last long enough to put you under water if you’re not prepared for the possibility. Do your best to keep a buffer and pay close attention to collections. Understand the client’s payment process, who is involved, and how long it takes; investigate immediately if the pattern starts to quaver.
Indie dev mistake No. 10: Hiring people before you have (enough) paying work for them
A chief concern when going independent is knowing when it’s time to no longer go it alone. While staying lean at the expense of adding help is the norm for some, it’s nearly as easy to overestimate the scope or certainty of new projects and bring on eager, even inexpensive talent to help. After all, the only way to grow is to grow, right?
But this can increase your overhead significantly without increasing your revenue -- in terms of both budget and time. Changing processes to accommodate new head count, training new hires, managing workloads -- it can quickly derail your ability to close sales and deliver the quality your customers have come to expect. Hire cautiously.
Indie dev mistake No. 11: Thinking there are shortcuts to sales success
Most developers who go independent do it to solve problems, write code, and deliver results. They may not enjoy marketing and sales activities, but these activities can’t be ignored -- and I do not recommend that you outsource them completely, at least not initially.
There are no shortcuts to sales that work reliably, and each technique and tool alters your process in ways both subtle and gross. Long shots happen, but don’t bet the farm on them; instead focus on steady, reliable, refinable systems that you thoroughly understand.
Evaluate each marketing/sales tactic and tool with the same critical eye you would use when deciding to adopt a new programming language or IDE. Play with it, run some tests and benchmarks, consider how it impacts everything else you’re doing, and resist the urge to change directions too frequently. Even the most reliable, time-tested, surefire sales techniques take time and tweaking to work, so set realistic expectations and timelines, and be wary of abandoning existing systems before you understand them. If you hopped on the latest programming trend every month, you’d never finish anything and would quickly go out of business. The same applies to marketing/sales tools and trends.
Like it or not, there is no escaping the basic marketing/sales education process, learning curve, and effort. Go talk to prospects. There’s no other way to learn this aspect of your business.
Indie dev mistake No. 12: Failing to document, refine, and automate processes and systems
Processes and documentation may seem like the stuff of slow, dinosaur companies -- they may even be the chief reasons you left your corporate job -- but the truth is, an efficient independent software business depends on them.
Chances are you already have processes you have followed, repeated, and refined for years. Some you may have even taught, directly or indirectly, to others. Do yourself a favor: Write them down, discuss and refine them often, and automate wherever possible.
Automation is your bread and butter. You probably extol the virtues of automation to your clients all day long. But your own internal systems are manual or nonexistent. This makes results somewhat unpredictable; worse, it wastes your time -- and for an entrepreneur, time is the most critical nonrenewable resource.
Manual or hacked-together systems are fine to start with, but don’t stay satisfied with them. Removing tedious, repetitive work reduces friction across all processes.
Look first at where most of your nonproductive time goes, and automate that. “Automation” in this sense includes all options, from fully automatic software systems that do everything for you while you sleep, to virtual assistants to personal assistants to outsourcing specialists and any combination of the above.
Indie dev mistake No. 13: Dropping the ball when it comes to support
Poor support is a major reason why clients change service providers. The less support needed, the better, but being known for excellent support is pure gold -- not just because it maintains customer relationships after sales and delivery, but because outstanding support turns your customers into evangelists.
This doesn’t only mean fixing problems in the middle of the night. It means helping clients understand every facet of your solution, teaching them how to perform tasks and fixes themselves, and providing all of the information they need to remain confident they made the right choice for their business’ future.
Because that’s what you build for your clients: their future. You may not have to live in it for long, but they do. Support their decision and vision, and reinforce and reassure them. There is no such thing as “not my problem.”
Indie dev mistake No. 14: Becoming a bottleneck to your own success
When you go it alone, every decision is important, and because it’s your business, you’re on the hook to make every one of them. As your company grows, the decisions mount -- which projects to pursue, how to juggle workloads, where to investigate new leads -- and they can quickly dam up and destroy the company.
With clear guidelines, responsibilities, and processes, delegation can be your most valuable tool, and one that can be comfortable even for the most control-freakish of development shop owners. Know when and how to delegate effectively -- or die.
This story, "The 14 mistakes that will kill your independent development shop" was originally published by InfoWorld.
at 11:27:00 AM
Last year, when Target's CEO and CIO resigned in the wake of one of the largest thefts of payment card info in history, a seminal moment seemed to have arrived: At last, C-suites everywhere had been put on notice. The consequences of not taking security seriously were abundantly clear.
Since then, unabated, the parade of household names beset by data breaches has rolled on: Michaels, PF Chang's, Community Health Systems, UPS, Dairy Queen, Goodwill, Home Depot, JP Morgan Chase, Kmart, Staples, and most notoriouslySony, where the consequences -- not only for Sony Pictures exec Amy Pascal, but for the storied brand itself -- were catastrophic.
In the face of such carnage, how is it possible that nothing seems to change? As InfoWorld's Roger Grimes proclaims again and again, the best practices to prevent successful attacks are almost painfully obvious. Prior to the 2014 attack, Sony's defenses already had a reputation for being thin. Roger used the Sony breach as occasion to remind us that "the overall state of computer security at most companies is pathetic."
Security awareness has climbed to extraordinary heights as a result of these breaches, yet one of the safest predictions you can make is that we'll see more high-profile disasters this year. Given the stakes, how could this be? Here's my speculation.
1. Playing the odds at the top
Security efforts cost money and dent productivity by adding extra steps to normal operations. No captain of industry earns accolades by reducing risk, but short-term profitability pays handsomely, and chief execs tend to change jobs frequently. What are the odds a high-profile breach will occur within a few years' tenure? Higher than a few years ago, perhaps, but as Arijit Chatterjee and Donald Hambrick observed in their landmark 2007 Penn State study, "It's All About Me," CEOs often display narcissistic tendencies, and narcissists embrace risk.
2. Listening to vendors
Security vendors are in the business of hyping the latest threats (to the point ofcreating logos for them) and selling magic bullets to combat them. Technically, these threats are real, but represent a tiny risk relative to such obvious attack vectors as exploiting unpatched systems. Believe the hype and you'll divert resources away from where they're needed most.
3. Caving to operational pushback
Let's say management gets religion and decides to eliminate the No. 1 risk in its organization, client-side Java. But then, uh-oh, several LoB managers pipe up to object that certain critical applications depend on client-side Java. In fact, a couple of crucial apps require older Java versions that are utterly exploitable. Does the company really want to bring operations to its knees while those apps are re-created using some safer technology? Or should that happen, say, during the big technology refresh planned for next year?
4. Failing to explain the obvious
Admins assume only an idiot would click on a random file attachment, follow a link to a malware-infested site, or react to a fake virus alert by installing fake antivirus software that's actually malware. But the fact is phishing emails have become very, very good, and if you've never seen what happens when your real antimalware software detects a Trojan, how do you know what's fake and what isn't? Users need structured security training, along with prompt warnings when phishing exploits circulate. Training needn't take long but must be ongoing.
5. Assuming invulnerability
Firewalls, intrusion detection systems, security event monitoring, network monitoring, two-factor authentication, identity management … your company has it all. Nobody is getting in! Yet the sad fact is if you have something to steal, you've already been hacked. Wrapping one's head around that idea creates the proper mind-set -- to encrypt critical information at rest, to avoid enabling permanent admin privileges, and to implement other measures that minimize damage after bad guys cross the perimeter.
6. Succumbing to fatalism
I often think that many enterprises know how horrific the problem is. But what can they do? The professionals who launch APTs (advanced persistent threats) are almost unstoppable. The financial industry sees the many billions lost to fraud and cyber theft each year as part of the cost of doing businesses. We're all going through the motions. The bad guys have won.
There's an element of truth to this last point, since exploits are always one step ahead of defenses. Yes, attacks are inevitable -- but that's no excuse for laxity when it comes to best practices, which vastly reduce the attack surface area.
Procedural change of any variety messes with people. But letting sloppy security practices persist will almost certainly make you a big, fat target. Which will it be? Bureaucratic inertia tinged by persistent fear? Or the discomfort of adding overhead in order to slash risk dramatically? You may never see a commensurate reward for the latter, but personally, I prefer being able to sleep at night.
This story, "6 reasons why improving security is so hard" was originally published by InfoWorld.
at 11:25:00 AM
Potentially offering a boost for web server software worldwide, Google has released as open source a framework for HTTP/2, the newly updated standard for transmitting Web pages and Web applications over the Internet.
The software, called gRPC, handles remote procedure calls (RPC) between servers and clients, such as browsers or mobile applications. It is based on HTTP/2, which was ratified as a standard earlier this month by the Internet Engineering Steering Group (IESG).
"gRPC is based on many years of experience in building distributed systems," wrote Mugur Marculescu, Google product manager, in a blog post announcing the code.
The gRPC framework powers most of Google's services today, fielding tens of billions of Web calls every second.
In development for a number of years, HTTP/2 could goose Web performance in a variety of ways, such as through header compression and the ability to send multiple requests at once over a single connection.
Based on Google's own Spdy protocol, HTTP/2 could speed web traffic as well as significantly reduce power consumption on battery-reliant mobile devices.
The gRPC platform can be integrated into multiple languages, including C, C++, Java, Go, Node.js, Python, and Ruby. Google is also working on libraries for Objective-C, PHP and C#.
In addition to Google, HTTP/2 also found a home in the latest Firefox browser:Firefox version 36, released earlier this week, also supports the fresh protocol.
Not everyone is on the HTTP/2 bandwagon, however. Poul-Henning Kamp, the developer of the FreeBSD operating system, has said that HTTP/2 is overly complex, provides no additional user privacy checks, and, despite Google's claims otherwise, probably isn't any faster than the original HTTP.
This story, "Google shares code to help server software digest HTTP/2" was originally published by javaWorld.
at 11:23:00 AM