Life as Code

refactoring my life

Archive for the ‘Development’ Category

cause and effect – more testing doesn’t necessarily improve software quality

with 2 comments

A short story about cause and effect I had in my backlog.

Jim works for a software company or, why not, he may even own it.

Jim realizes that the quality of the software that gets built in his company decreases year-by-year, all over the board. He’s been seeing it for some time now but it seemed like the guys have it under control. You know, the guys know what they’re doing.

After awhile things seem to slip even further….

Read the rest of this entry »

Written by Bogdan

October 17, 2013 at 11:49 PM

the best way to serve static files from Sinatra

with 2 comments

I’ve been using Ruby for a couple of years now, mostly for utility scripts (organizing family pictures, generating XML files, processing CSV files… it’s good for these types of things) and for web prototypes but lately I’ve started to get the taste of it.

Read the rest of this entry »

Written by Bogdan

January 24, 2013 at 1:19 AM

Posted in Development

Tagged with

what’s in a name: Single Page Application

leave a comment »

Just found out that there’s a name for the type of apps that we’ve been working on for the last couple of years. It even has a catchy acronym.

So, you know those RESTful API accessing, JavaScript + JSON powered, highly dynamic, limited HTML web apps that everybody is developing lately?

Those are actually Single Page Applications, or SPAs. There’s even a Wikipedia entry describing the 10 year history of SPAs.

The only good thing is that the page mentions thin server architecture, which is a big win, and probably the only thing that makes sense – the rest is just somebody misspelling AJAX driven web app.

Written by Bogdan

October 31, 2012 at 12:52 AM

Posted in Development, Fun

Comparing SaaS Cloud apps hosting and provisioning options

leave a comment »

This is what popped up while going through a thought experiment on choosing hosting and provisioning for the development of a new Software as a Service offering.

The options considered are:

  • PaaS with multi-tenancy – use a PaaS offering (think Cloud FoundryHeroku, Google App Engine and Windows Azure Compute) to host a multi-tenant system. Provisioning for a new client is zero-cost done inside the system
  • PaaS with one environment per client – use a PaaS offering (think  Cloud FoundryHeroku, Google App Engine and Windows Azure Compute) to host a regularly developed system. Provisioning for a new client means configuring a new PaaS environment, adding an instance and deploying
  • IaaS with multi-tenancy – use an IaaS offering (think Amazon EC2 or Windows Azure Virtual Machines) to run a stack of Virtual Machines configured to run your platform of choice, hosting a clustered multi-tenant application. Provisioning is zero-cost after initial setup
  • IaaS with one stack per client – use an IaaS offering (think Amazon EC2 or Windows Azure Virtual Machines) to run one stack of Virtual Machines configured to run your platform of choice, hosting a clustered (or not) regularly developed application for each client. Provisioning means creating stacks, adding virtual machines, installing OS, DB, platform and deploying application

For convenience I also added a category called UGLY, just to highlight what I consider to be the worst point of each option.

SaaS

Over PaaS with multi-tenancy

Over PaaS with one environment per client

Over IaaS with multi-tenancy

Over IaaS with one stack per client

GOOD

  • Application must comply with platform constraints
  • One version for all clients
  • Single location deployment
  • Automatic scaling
  • Simpler, faster provisioning
  • Simple monitoring at the application level
  • Looks cheaper, pay by CPU-time and resource usage
  • Application must comply with platform constraints
  • Allows for multiple versions at the same time for different clients (even deep customization)
  • Automatic scaling
  • Simpler provisioning
  • More control in choosing platform and technologies
  • One version for all clients
  • Can use farm-deployment for single location deployment
  • Simpler, faster provisioning
  • Simple monitoring at the application level
  • More control in choosing platform and technologies
  • Allows for multiple versions at the same time for different clients

BAD

  • Application must comply with platform constraints
  • One version for all clients
  • Application has to know about multi-tenancy – it should be designed to support it
  • Application must comply with platform constraints
  • Must have tight configuration management to handle different versions for different clients
  • Provisioning may be slower, depending on instance creation speed
  • Complex monitoring
  • Must handle horizontal and vertical scaling
  • One version for all clients
  • Increase in deployment architecture complexity
  • Must handle clustering and state
  • Application has to know about multi-tenancy – it should be designed to support it
  • Must handle horizontal and vertical scaling
  • Must have tight configuration management to handle different versions for different clients
  • Must handle different deployments and deployment scenarios
  • Complex monitoring

UGLY

  • Platform may enforce application architecture and technologies
  • Platform may enforce application architecture and technologies
  • Must manage operating system, storage and database configurations
  • Must manage multiple, possibly different operating systems, storage and database configurations

 

Some points are good and bad simultaneously. Examples:

  • Application must comply with platform constraints – which means that you can’t always do what you want to do, producing
    • GOOD – sometimes enforces good coding and resource-usage conventions
    • BAD – more effort in developing exotic things
  • One version for all clients – there can only be one version in production
    • GOOD – less versions to worry about, less things to manage
    • BAD – you may upgrade users that want the old version or you may have some users that want deep customizations and that are willing to pay for them

The overall conclusion is that the higher you go, the less you have to manage, the cheaper it gets.

For another good read you can check out the PaaS vs IaaS comparison on http://www.engineyard.com/paas-vs-iaas.

Written by Bogdan

October 29, 2012 at 11:35 PM

Users and their strange habits

leave a comment »

Users are strange creatures, and to demonstrate, here are some quick facts:

  • They want to achieve lots of things as fast as they can, without learning anything new;
  • They hate reading and avoid anything that resembles help or a user manual… or even freaking text boxes;
  • They want user interfaces that look like other user interfaces and that function the way that other applications function but that ultimately achieve a different goal;
  • They want things to just work.

Yup, strange creatures indeed. Who would have thought? Not us programmer types anyway.

None of these facts are new. All of them are known since the dark ages of computing. All of them are well documented and repeatedly demonstrated. It just seems that a lot of the things that we used to know and follow are now forgotten.

Users want well designed products that are tailored to their needs and that help them do what they want to do. Users  just don’t want to read the manual and they have  chronic dialog box blindness. For users, the user interface is the product so if you want them to use your product they need consistent and usable interfaces. Users need professionally designed, developed and  production-ready products that just work; not unfinished, buggy, wanna-be software.

Because users are ultimately our customers and because it is the right thing to do if we consider ourselves professionals that is what we must provide. Because that is what they deserve.

You can consider this post a small rant – just blowing off some steam after re-iterating some of these facts to a bunch of confused developers that think users are just plain stupid. They’re not stupid – we are just building software for the wrong people (rocket scientists that can read binary while unit testing in their sleep).

Written by Bogdan

October 9, 2012 at 10:32 PM

Replacing images and icons with CSS3 web fonts

with 2 comments

It’s really hard to create beautiful and clean web interfaces when you have to slice and dice images for every little button, action or highlight. Well, now you can replace them with web-font characters styled with CSS3 – as most browsers have support for them.

Here’s a sample from something I’m working on just to give you a feel:

Image

Wait, there’s more: using styled glyphs instead of images gives you more flexibility with application themes – and less images to mess with:

Image

The nice thing? What you’re actually seeing above is :

<div id="header-toolbox">
     <a href="">c</a> 
     <a href="">U</a> 
     <a href="">S</a>
     <a href="">X</a> 
 </div>

It’s actually dynamically built with JavaScript but you get the idea.

The font that I’m using for the glyphs is Web Symbols, available from http://www.justbenicestudio.com/studio/websymbols/

Written by Bogdan

September 29, 2012 at 3:16 PM

Fastest web stack you could possibly set up for prototyping

leave a comment »

You should be already used to my religious prototyping habits – I tend to try out a lot of stuff, build a lot of things that I later discard and so on.

Knowing that I do this a lot, I tend to actively look for tools that are either very easy to set up or that don’t even have an install footprint. Last year (I think) I found Mongoose, and used it to replace my normal prototyping instance – an Apache instance that I had running all the time on my dev machine.

Mongoose turned out to be the best choice, being just an executable (small – in the hundreds of kilo range) that you can run to get an instant web server, serving files from any folder.

My normal usage is to copy the Mongoose binary and a small config file to an empty folder and then to start churning out HTML, CSS and JavaScript – and it worked fabulous… until I needed something dynamic and I was forced to switch back to Apache.

Well, tonight I got my revenge. I needed some dynamic calls to test a RESTful API, and because my API builder is not ready yet I had to resort to some fast PHP hacking.

As my new home dev machine is not fully configured yet and I had no Apache installed and configured I thought what the hell, how’s about trying to hook up the Mongoose CGI. I knew it had support for it but I never tried it before, until now.

So, without further a due, I present the fastest setup for a prototyping web stack (on Windows) ever:

1. Create a folder – duh

2. Get the latest Mongoose binary from http://code.google.com/p/mongoose/downloads/list and copy it to the folder

3. Get the latest PHP zip distribution from http://windows.php.net/download/, unzip it and copy the php support files for CGI to the folder (php-cgi.exe, php5.dll and php.ini are enough)

4. Create a mongoose.conf file with the following lines:

listening_ports 80
document_root .
cgi_pattern **.php$
cgi_interpreter .\php-cgi.exe

5. Run the Mongoose binary (I usually rename mine to mng.exe) and access it with your favorite browser

And that’s it, you now have a web server and PHP configured, all under 5 minutes. Enjoy!

You should only use this for prototyping stuff – NOT FOR ANYTHING SERIOUS LIKE A PRODUCTION OR CLIENT-ACCESSIBLE INSTANCE!

Written by Bogdan

September 27, 2012 at 11:11 PM

Stop Visual Studio Express 2012 from SCREAMING at you

with one comment

I don’t develop .NET code professionally but I do like to keep my tools sharp in every direction – that includes knowing the latest technologies even if they don’t relate to JEE.

Playing around with .NET means I need a good environment at a reasonable price (read free) and after trying SharpDevelop and VS Express a couple of years ago I decided that the best IDE for me was VS C# Express.

After happily using it for more than 2 years I upgraded to VS Express 2012 for Windows Desktop (there’s no C# edition anymore) and surprise – the menus WERE SCREAMING AT ME IN ALL CAPS.

At first you ignore it but after a while it becomes really annoying so I decided to fix it.

I asked around and I found a post by @shanselman that mentioned a registry trick to stop VS from capitalizing menus but it only worked for a full install of Visual Studio and not for Express.

I fired up my trustworthy procmon, identified the registry path for VS Express, tried it and it worked. Here’s how it looks like:

Image

If you want to fix it too, here’s the registry key and value that you need to create:

HKEY_CURRENT_USER\Software\Microsoft\WDExpress\11.0\General

SuppressUppercaseConversion

DWORD value of 1

Written by Bogdan

September 19, 2012 at 10:02 PM

Posted in .NET, Development, hack

Tagged with

Apis – The Web API builder

with one comment

 

I KEEP six honest serving-men

(They taught me all I knew);

Their names are What and Why and When

And How and Where and Who.

Rudyard Kipling

 

What?

In Prototyping the web API I started describing an idea to build a tool that can be used to try out/prototype web APIs before actually building a back-end implementation, helping a team to describe a clear and strict HTTP API, as well as allowing them to build and test client code without having written one line of server-side code.

This post is taking those ideas further, trying to crystallize the concept, objectives, goals and my overall expectations of this tool.

Based on my previous attempts at crudely building a harness for my web development habits, I’ve outlined a sort of a wishlist.

Apis, as I’ve so naively chosen to name this tool will be a part of my typical development stack and must:

  • Have a pleasant, easy to use interface where I can define the desired HTTP API, including endpoints, request and response configuration that I can export as a well-structured definition document;
  • Allow me to save the definition in a human readable and human editable format that can also be saved, compared and merged in a VCS;
  • Allow me to define standard responses for each API endpoint based on the request configuration so I can test the API, build a proof-of-concept API and even build a whole user interface decoupled from back-end services;
  • Allow me to define static resources that will be served alongside the standard responses, such as JavaScript frameworks, CSS styling and any other kind of resource I want to serve;
  • Be standalone and packaged in an easy-to-use installer so I can send it to my fellow developers that can load the API definition from VCS and work on it.

That’s about it. If it seems pretty simple, it’s because most useful things are, and should be…. simple.

Why?

This is a simple one:

  • I like a well-defined, clear and strict web API in my projects. I want others to want one too;
  • I like to prototype a lot. I want to be able to quickly prototype a web interface without having to set up a web server or -hell no- a full development environment. I want to make it easier for others to prototype;
  • I want to test my decoupled web clients in a clean, well-known state and I want my server-side code to have no idea who they’re talking to.

How?

This is a simple one too:

  • Not like I did before. I want a desktop app, not a whole bunch of code, glue and configuration files;
  • I want to build it clean, so I can easily extend it. I don’t really care about other operating systems than Windows so I’ll build a Windows desktop app;
  • No bloody way I am building it in some scripting language again and I code Java professionally so I don’t want to do it in my spare time. Plus, I really like C#, the .Net stack and WPF;
  • I’ll build it in my own time, build it right, and build it for myself (for a change).

So, Windows, C#, WPF, VS Express and a whole lot of will power it is!

I’ll build it iteratively and story-based. I won’t say agile because well, for an agile process treating communication and people problems… let’s say that you need a minimum of two people for hate or love.

When, Where and Who?

There’s no better time than now and no better place than wherever I am. The Buddhists say it well “Wherever I am, I am home, I am now, I am free”.

I’ll start building it alone. I know it’s not a good idea to work alone, that in programming, one is the loneliest number but later on, if it catches on, I’ll try to get some other people on board.

I’ll host everything on gp… it’s been lonely since the migration to WordPress.

That’s it for now. I was storing this in my brain, which is stupid… that’s why I have a blog.

 

Written by Bogdan

September 14, 2012 at 8:15 PM

Prototyping the web API

with 2 comments

 

Since my ideal web application model includes a decoupled web client and since I favor an interface-first approach while prototyping and development, I always try to code the user interface as decoupled as I can from the web tier.

At first, I’ve tried developing the web components (HTML, JS, AJAX and all) as standalone packages, not integrated in the user interface. Well, that works… the only problem is that it leads to hacks and to a “one API per user interface” approach, which I really hate.

Seeing this, I started to develop my web interfaces disconnected from the web-tier, by mocking the data services using:

  • simple files served by a vanilla Apache instance;
  • which evolved into a ruby environment running Sinatra;
  • which ultimately turned into a node-js dynamic application…. which frankly feels like I’m shaving yaks using rugged stones (mostly because it’s just a bunch of JSON configuration files that you have to edit manually) so I’m now going to replace it with something new – something usable that can really cut my effort.

The idea is still evolving but what I want the final product to do is:

  • serve static files (for web client files and frameworks);
  • allow the user to actually build a web client application with no backend;
  • let the user define dynamic answers to HTTP requests in a simple way, defining an API of all the service calls that the client will need to fully function;
  • let the user export the defined API in a readable format;
  • let the user save his work in a human-readable format that can be stored in VCS.

 

While building this thing I’ll have to build a sample / proof of concept app just to test the beast.

Written by Bogdan

September 13, 2012 at 10:04 AM

Posted in Development

Follow

Get every new post delivered to your Inbox.

Join 259 other followers