Sunset Pool Screenshots

Here are a pair of new screenshots from Sunset Pool (our upcoming mobile game). The first is a larger level in the "Dusk" set of the first episode. Though the level is large and has plenty of spikes, its object shapes are close to their respective goals, limiting the level's difficulty.

(click to enlarge)

The second level is taken from the "Nightfall" set of the same episode (I call them episodes development thanks to playing too many id software games as a kid. I have a feeling I'm not alone).

(click to enlarge)

Both of these screenshots will be submitted to Screenshot Saturday on reddit.com when it goes live in a few hours, along with an animated GIF of an in-game sunset.

10 Good Reasons to Choose iNMR

1. iNMR is a single application that includes a multitude of specialized modules. When you buy a license you get everything. Most of our competitors, instead, give you the basic functionality only and then ask you more money for the additional modules and the yearly upgrades. With iNMR you just pay once and receive years of upgrades and support.
2. You are not locked in. iNMR always works with the original spectrometer files. Any additional information that you generate is stored into short and readable XML files that you can open with countless external applications. Your experimental data remain readable by all other NMR software in circulation.
3. You'll receive email supportdirectly from the author, 360 days per year, from 8 AM to 12 PM (Central European Time, UTC+2 from April to October, UTC+1 otherwise). If necessary you can receive a patched or customized version in a matter of hours. This is what you pay for when you buy a license.
4. You can further extend the functionality of iNMR with your own scripts, thanks to the embedded Lua interpreter. Lua is a first-classprogramming language which is the ideal in terms of versatility and speed. Only two NMR programs include a Lua interpreter: CARA and iNMR. If you don't know the language we'll write the scripts for you. Gratis.
5. iNMR is a native Windows application that directly calls the traditional Windows APIs, something unique in the NMR field. iNMR is written in C/C++ and takes for itself only a minimal amount of disc space and memory. You can't say the same thing about other NMR programs, which are built upon several intermediate layers of software.
6. Microsoft explicitly recommends to embrace Direct2D as the drawing API for new applications. iNMR is the only NMR program to follow the advice and the results are amazingly clear plots, fast drawing of large matrices and assured support by future versions of Windows.
7. The graphic interface is the simplest and the tidiest. More screen estate is available for spectroscopic contents, you are not distracted by unnecessary widgets. The optional keyboard shortcuts are easy to memorize and increase your productivity.
8. The same license is valid for many kinds of computers. iNMR is available for the last 3 major versions of Windows and 6 versions of Mac OS, which means 59%of the active computers. Any PC built in the last 8 years is good.
9. As a working tool, iNMR has already been successfully tested by thousands of Mac users since 2005 and hundreds of Windows users since 2012.
10. For industrial customers iNMR represents by far the cheapest offer on the market. Figures speak for themselves.

Thursday's screenshot

(click here to enlarge)

I'll be posting these screenshots, plus an animated GIF of the above level, on Screenshot Saturday (r/gamedev on reddit) tomorrow evening when that thread goes live. Looking forward to getting some feedback from someone other than my art guy :).

New screenshot

Here is your new screenshot of the day. The sun has set in our little world:

(click here to enlarge)

So what's next?

Drawdle has been doing pretty well since being featured on Google Play last fall (thanks again, guys). However it's been nearly two years since Drawdle was released (1 year, 8 months to be exact), making it well past time for me to give everyone an update on the next game. Since early in the summer last year, I've been working on something new in my spare time. Here is a teaser image (I plan to release one of these per day for the next three days):

(click here to enlarge)

I also plan to announce the game name on Friday, but no promises. Hopefully the screenshot gives a pretty good idea about the gameplay, which can be summarized as "billiards in the sky" for now.

Drawdle took about seven months to complete, working in my spare time (though the physics engine was largely finished beforehand). I was hoping to finish this game on similar terms, but given its added complexity and polish, it was clear that working part-time meant it would never get done. It is hard enough for a team to complete a game, let alone a team of one, let alone when that one has a day job also.

About three weeks ago I left said day job, and have been working (more than) full time on the new game since. I must say that so far I love it. Time really flies when you are working for yourself, but I've never felt more productive.

There is no denying that this is a big gamble, however. Most small businesses fail, and independent game studios are far from an exception. Drawdle's relative success has given me this opportunity, but this game must be even more successful for this gamble to pay off. Wish me luck :)

Yes Small Companies Can – and Should – Build Secure Software

"For large software companies or major corporations such as banks or health care firms with large custom software bases, investing in software security can prove to be valuable and provide a measurable return on investment, but that's probably not the case for smaller enterprises, said John Viega, executive vice president of products, strategy and services at SilverSky and an authority on software security."


Schneier on Security: Is Software Security a Waste of Time?

Bullshit.

It’s foolish and short sighted to pretend that software security is only a problem for enterprises or enterprise software vendors. Small companies write software that big companies use, which means that these big companies are putting their customers at risk. This is happening all of the time.

And it’s wrong to believe that small shops can’t do anything practical about building secure software. I'm not talking about swallowing something like Microsoft’s SDL whole – for some people, the argument seems to be that

“If you aren't following Microsoft’s SDL then you can’t build secure software, and nobody except Microsoft can follow the SDL, so you might as well give up.”

But you don't need to adopt the SDL, or any other large-scale, expensive, enterprise-quality software security program. Any small shop can take some reasonable steps that will go a long way to building secure software:

1. First, take some time upfront to understand the business requirements for security and compliance and for handling confidential and private data – what information do you need to protect, who can see and change what data, what data do you have to encrypt, what data should you not store at all, what do you need to log? All of this is just part of understanding what kind of system you need to build.
   
   
   
   
   


2. Think about your application architecture, and choose a good application framework. For all the noise about “emergent design”, almost everybody who builds business apps – even small teams following Agile/Lean methods – use some kind of framework. It’s stupid not to. A good framework takes care of all kinds of problems for you – including security problems – which means that you can get down to delivery features faster, which is after all the point.
   
   
   
   
   If you’re a Ruby developer, Rails will take care of a lot of security problems for you – as long as you make sure to use Rails properly and you make sure to keep Rails up to date (the Rails community has made some mistakes when it comes to security, but they seem committed to fixing their mistakes).
   
   
   
   
   Play, a popular application framework for Java and Scala, includes built-in security features and controls, as do many other frameworks for Java, and frameworks for PHP and other languages, and of course there’s .NET for Microsoft platforms, which is loaded with security capabilities.
   
   
   
   
   None of these frameworks will take care of every security problem for you – even if you use them properly and make sure to keep them patched as security vulnerabilities are found. But using a good framework will reduce risk significantly without adding real costs or time to development. And when you do need to do something about security that may not be included in the framework (like properly handling encryption), there are good security libraries available like Apache Shiro that will make sure that you do things right while still saving time and costs.
   
   
   
   
   


3. Write solid, defensive code: code that works and won’t boink when it is used in the real world. Check input parameters and API return values, do a good job of error handling, use safe libraries. Program responsibly.
   
   
   
   
   


4. 
   Take advantage of static analysis tools to catch bugs, including security bugs. At least understand and use any static analysis checkers that are in your IDE and free, easy to use tools like Findbugs and PMD for Java, or Microsoft’s tools for .NET. They're free, they find bugs so you don't have to - why wouldn't you use them?
   
   
   
   
   Most commercial tools are too expensive for small teams, although if Cigital comes through with small-bundle pricing for Secure Assist this would finally provide small development teams high-quality feedback on security bugs.
   

Sure there is a lot more that you could do or should do if you need to. But even modest and reasonable steps will go a long way to making software safer for customers. And there’s no reasons that small teams can’t – or shouldn't – do this.

Book Review: The Phoenix Project

Everyone who attended the “Rugged Devops” panel at RSA this year received a free copy of The Phoenix Project (by Gene Kim, Kevin Behr and George Spafford – the authors of Visible Ops), the fictional story of the education and transformation of an IT manager, an IT organization, and eventually of an entire company.

I'm not sure why they wrote the Phoenix Project as a novel. But they did. So I’ll review it first as a piece of story telling, and then look at the messaging inside.

The reason that I don’t like didactic fiction is that so much of it is so poorly written – generally forced and artificial. I was pleasantly surprised by the Phoenix Project. The first half of the novel tells a story about an IT manager forced into taking on responsibility for saving his company. Our well-meaning hero, an ex-marine sergeant (for some reason unclear to me, the hero, the CEO, and even the mysterious guru all have a military background) with an MBA but without any ambition except to quietly provide for his family. He has been successfully running his own little part of the IT group, so successfully that he is dramatically promoted to take over all of IT operations (and so successfully that his own group is never mentioned again in the story – it seems to run on auto-pilot without him). For a successful manager, our hero knows alarmingly little about how the rest of the IT organization works, or about the business, and so is unprepared for his new responsibility. He reluctantly accepts the big job, and then regrets it immediately as he realizes what a shit storm he has walked into.

It’s a compelling narrative that draws you in and is seems realistic even with the stock characters: the sociopathic SOB CEO, the unpopular everything-by-the-book CISO, the Software Development Manager who only cares about hitting deadlines (but not about delivering software that works), the Machiavellian Marketing executive, and the autistic genius that the entire IT organization of several hundred people all depend on to get all the important stuff done or fixed.

As a pure piece of story telling, things start to unravel in the second half with the emergence of the IT / Lean Manufacturing guru – when the story ends and the devops fable begins. From this point on, the plot depends on several miraculous conversions: everyone except the marketing exec sees the light and literally transform overnight. They even start to groom themselves nicely and dress better. Lifetime friendships are made over a few drinks, and everyone learns to trust and share: there’s a particularly cringe-inducing management meeting in which people bare their souls and weep. Conflicts and problems disappear magically usually because of the guru’s intervention – including an unnecessary scene where the guru shows up at a crucial audit meeting and helps convince the partner of the audit firm (an old buddy of his) that there aren't any real problems with the company’s messed up IT controls (“these aren't the droids you’re looking for”).

But the real heroes are the people running the manufacturing group: the one part of this spectacularly mismanaged company that somehow functions perfectly is a manufacturing plant where everyone can all go to learn about Kanban and Lean process management and so on. Without the help of the smug and smart-alecky guru - who apparently helped create this manufacturing success - and his tiresome Zen master teaching approach (and sometimes even with his help), our hero is unable to understand what’s wrong or what to do about it. He doesn't understand anything about demand management, how to schedule and prioritize project work, that firefighting is actual work, how to get out of firefighting mode, how to recognize and manage bottlenecks in workflow, or even how important it is to align IT with business priorities (where did he get that MBA any ways?). Luckily, the factory is right there for him learn from, if he only opens his eyes and mind.

What will you learn from The Phoenix Project?

The other problem with this story telling approach is that it takes so damn long to get to the point – it’s a 338 page book with about 50 pages of meat. Like Goldratt's The Goal (which is referenced a couple of times in this book), The Phoenix Project leads the reader to understanding through a kind of detective story. You have to be patient and watch as the hero stumbles and goes down blind alleys and ignores obvious clues and only with help eventually figures out the answers. Unfortunately, I'm not a patient reader.

This is a gentle introduction to Lean IT and devops. If you've read anything on Kanban and devops you won’t find anything surprising, although the authors do a good job of explaining how Lean manufacturing concepts can be applied to managing IT work. The ideas covered in the book are standard Lean and Theory of Constraints stuff, with a little of David Anderson’s Kanban and some devops – especially Continuous Deployment as originally described by John Allspaw and Continuous Delivery.

The guru’s lessons are mostly about visualizing and understanding and limiting demand – that you should stop taking on more work until you can get things actually working so that you’re not spending all of your time task-switching and firefighting; identifying workflow bottlenecks and protecting or optimizing around them; how reducing batch size in development will improve control and to get faster feedback; that in order to do this you have to work on simplifying and standardizing deployment; and how valuable it is to get developers and operations to work together.

My complaints aren't with the ideas – I buy into a lot of Devops and agree that Kanban and Lean have a lot to offer to IT ops and support teams (although I'm not sold on Kanban by itself for development, certainly not at scale). But I was disappointed with the unrealistic turnaround in the second half of the book. It’s all rainbows and unicorns at the end. IT, the business, development and security all start working together seamlessly. Management is completely aligned. Performance problems? No problem – just go the Cloud. And they even bring in the famous Chaos Monkey in the last couple of pages just because.

Spoiler Art: Everything goes so well in a few months that the company is back on track, plans to outsource IT and to break up the company are cancelled, the selfish head of marketing is canned, and our hero is promoted to CIO and put on the fast track to corporate second in command. Sorry: nothing this bad gets that good that easily. It is a fable after all, and too hard to swallow.

The Phoenix Project is a unique book – when was the last time that you read an actual novel about IT management?! It was worth reading, and if it introduces devops and Lean ideas to more people in IT, The Phoenix Project will have accomplished something useful. But it’s not a book that you can use to get things done. There are lessons and recipes and patterns but they take work to pull out of the story. There’s no index, no good way to go back to find things that you thought were useful or interesting. So I am looking forward to the Devops Cookbook: something practical that hopefully explains how these ideas can work in businesses that don’t look all like Facebook and Twitter.

Timeline interattiva di PlayStation

In allestimento...

Peer reviews for security are a waste of time?

At this year’s RSA conference, one of the panel’s questioned whether software security is a waste of time. A panellist, John Viega, said a few things that I agreed with, and a lot that I didn't. Especially that

“peer reviews for security are a waste of time.”

This statement is wrong on every level.

Everyone should know by now that code reviews find real bugs – even informal, lightweight code reviews.

“Reviews catch more than half of a product’s defects regardless of the domain, level of maturity of the organization, or lifecycle phase during which they were applied”. What We Have Learned About Fighting Defects

Software security vulnerabilities are like other software bugs – you find them through testing or through reviews. If peer code reviews are a good way to find bugs, why would they be a waste of time for finding security bugs?

There are only a few developers anywhere who write security plumbing: authentication and session management, access control, password management, crypto and secrets handling. Or other kinds of plumbing like the data access layer and data encoding and validators that also have security consequences. All of this is the kind of kind of stuff that should be handled in frameworks anyway – if you’re writing this kind of code, you better have a good reason for doing it and you better know what you are doing. It’s obviously tricky and high-risk high-wire work, so unless you’re a team of one, your code and decisions need to be carefully reviewed by somebody else who is at least as smart as you are. If you don’t have anyone on the team who can review your work, then what the hell are you doing trying to write it in the first place?

Everybody else has to be responsible for writing good, defensive application code. Their responsibilities are:

• Make sure their code works – that the logic is correct


• Use the framework properly


• Check input data and return values


• Handle errors and exceptions correctly


• Use safe routines/APIs/libraries


• Be careful with threading and locking and synchronization

A good developer can review this code for security and privacy requirements: making sure that you are masking or encrypting or – even better – not storing PII and secrets, auditing, properly following access control rules. And they can review the logic and workflow, look for race conditions, check data validation, make sure that error handling and exception handling is done right and that you are using frameworks and libraries carefully.

This is what code reviews are for. To look for and find coding problems. If you find these problems – and code reviews are one of the most effective ways of doing this – your code will be safer and more secure. So I don’t get it. Why are peer reviews for security a waste of time?