Archive for the ‘Working smart’ Category
Replacing images and icons with CSS3 web fonts
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:
Wait, there’s more: using styled glyphs instead of images gives you more flexibility with application themes – and less images to mess with:
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/
Fastest web stack you could possibly set up for prototyping
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!
Simon Sineks “Golden Circle”
“People don’t buy WHAT you do, they buy WHY you do it! And what you do simply serves as a proof of what you believe!”
If I could say it better I would, but I can’t so here is the TED clip.
A project objectives checklist
Objectives help your team to focus on the tasks at hand while not losing sight of the overall outcome that it needs to reach.
A good team is results-oriented, focusing on what it is trying to achieve not what it’s currently doing.
Use this checklist to verify that the objectives defined for your project will help you achieve results and won’t hinder your efforts.
-
Are the defined objectives clear enough?
Contrary to goals, objectives must be focused and clear. Understandable objectives will drive the team to successful results.
-
Are the defined objectives SMART?
Do the objectives comply with the SMART criteria:
- Specific
- Measurable
- Achievable
- Relevant
- Time constrained
-
Is the number of objectives right (4-6 range)?
There is no right number of project objectives but taking into account the fact that objectives should be known and tracked by the team, a low number (having between 4 and 6 objectives is a good compromise) will make it easier for the team to keep focused on the essential. Remember, the more objectives you have, the harder it will be for your team to keep track of them.
-
Is there a known and clear context?
The defined objectives must be linked to the overall context. Objectives that do not advance the project (useless objectives) or that are contrary to company strategy (like building a whole new product that competes with one that already exists) should be eliminated or changed. For each objective yourself these questions:
-
Will achieving this objective advance the project?
-
Does this objective tie in to the project and company goals?
-
Does this objective follow the company strategy?
-
-
Are the defined objectives known and agreed upon?
It is important that all stakeholders know and agree to the defined objectives. It is very important for project success that the objectives are known and agreed upon by project sponsors and executives.
-
Can each defined objective be tied to a deliverable?
Think of this as a post-SMART check. If you can pinpoint at least one deliverable that helps you attain an objective you are OK. If you can’t ask yourself this: how are we achieving this objective? If it doesn’t matter, you should remove it from the list.
-
Does every defined objective have quality criteria specified?
Besides being measurable, each objective should have quality criteria defined, so that both quantitative (are we there yet?) and qualitative (is it the right thing?) parameters can be tracked and accounted for. Getting it right is just as important as getting it done.
The photo wall – lessons about plans, changes, risk mitigation and results
I live my life following a simple set of rules:
- Measure twice, cut once
- Change is normal, expect and embrace it
- Hope for the best but expect the worst
- The quality of the end result is never an accident, it is always the result of intelligent choices and hard work
I apply these rules to everything I can, starting with preparing and following a simple shopping list, small home projects and ending with my day to day job.
Here’s the simplest and most intuitive example: my new photo wall, which I had to build in the week that my wife was on a business trip.
The process
- Define the outcome – I wanted a photo wall built with happy colored frames and pictures of my family that would fit in the hallway between my bedrooms – this took about five minutes;
- Analyze the location and identify the materials – I knew what I wanted so I searched for photo frames of different proportional sizes and happy colors and I selected the pictures from my photo collection (pictures chosen out of roughly 34GB of previously filtered photos). I also measured the hallway and calculated my constraints – this took about three days;
- Design the product – I built an Excel simulation of my photo wall where I laid out different frames of different sizes and colors and placed different pictures until I got the mix right;
- Test the design – I placed the photos in the photo frames and laid them out on the floor in the exact pattern. I isolated the ones that I did not like (color combination was wrong, photo did not fit in the overall picture, etc.)
- Modify design based on test feedback;
- Implement the design.
Risk mitigation
- I knew that I will surely select pictures that I won’t like – so instead of choosing only the 10 pictures I used in the simulation, printing them and getting it wrong (which would have made me miss my deadline) I selected and printed about 20 pictures of various sizes;
- I knew that I will surely change my mind about what will the color placing will be when I tested the design – so I bought 50% more photo frames of various colors;
- I knew I would mess up the positioning of the photos, even if I used rulers and drew lines on the wall – so I bought double adhesive tape that would only dry after 5 minutes, leaving me a change to unglue the pictures and straighten them
Change is good
Why expecting change and embracing it is a good thing:
Design – this is how my simulation looked like:
While I worked on it I really liked the feel and loved the layout and coloring.
I went on to testing.
The test and implementing the feedback – this is how my layout changed after the test:
As you can see, I changed two pictures (both content and frame color) – that’s a 20% change from the original design but an overall improvement in the color balance and the overall aspect.
The result – this is how the final setup looks like:
Now isn’t that nice?
I actually finished an hour and a half before my deadline and had time to prepare and place 4 more photo frames around the house – nothing is lost, everything is used J
I try to learn from everything I do and my lessons here were once again:
- Measure, analyze, prepare – then prepare some more;
- Expect and embrace change – change is good for you, actively look for it;
- Expect the unexpected – prepare for it;
- Effort and determination pay off in the quality of the end result.
Apis – The Web API builder
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.
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.
Getting it right – why checklists matter
Our lives and jobs are growing in complexity by the day and nothing seems simple anymore.
For everything that we have to do our mind builds a procedural path, adding more and more steps as the thing increases in complexity, and well… contrary to popular beliefs our minds are not especially good at remembering things, especially taking account the way that most of us work this days – multitasking, a proven productivity killer.
If multitasking is a productivity killer then multitasking complex tasks is a serial productivity killer and our minds start losing focus on the tasks at hand, the stages and prerequisites – which lowers the quality of our work even further.
The best way to counterbalance this loss of productivity and quality is to build lists of things that you need to do in order to deliver and follow them because, you know – writing it down is good, doing it is better.
Although checklists may seem similar to TODO lists they are different. The goal is the same – remembering what you need to do – but the nature is totally different.
TODO lists are about getting things done but what is the purpose of Getting Things Done if you’re not Getting Things Right?
T0 get things right, you need a checklist that should represent the level of quality and quantity that you expect from the final deliverable of a certain task.
Ideally, for each type of deliverable of each one of your tasks you should start building a checklist – while you are working of a task of that kind.
In time, each time you go into a task you should follow the checklist so that you never forget what must be done.
If you find new things that have to be done, refine the checklist until it fully satisfies the level of quantity and quality desired.
Start Getting Things Right… for a change.
Sketching my ideal web application model
Ever since I started working on my first real AJAX web components more than five years ago I’ve been a big supporter of the “Browser as a RPC client” architectural concept, promoting decoupling the “web client” from the “web tier” as much as the technology used in each project allowed, and I’ve met both resistance and support from each one of the teams I’ve worked in. Somehow, the thought of treating the “web client” as a distinct and separate entity from the “web tier” managed to evoke either alien feelings or hard-to-forget memories of client-server architectures in the hearts of my fellow developers.
In time, this changed as more and more developers started embracing AJAX and preferring MVC architectures… but we are not there yet. Resistance is still there, justified by arguments like “decoupling will incur extra costs” or “what’s wrong with generating pages server-side, it just works”.
I had my first try at building an application based on the model that I’m describing back in 2008, for my bachelor’s degree thesis and managed to do a pretty decent job considering the time, the maturity of the technologies and the stack that I selected but what I achieved was a lot less than what I hoped for. After I finished with my thesis I implemented a part of the concepts that I used in the projects that I worked on professionally and got pretty good results.
Having this first working spike outlined (at least for me) some of the most important benefits that we may get by using this kind of model, and I’ll try to summarize them:
- it enforces the creation and evolution of a clear and strict client-server API and cleaner code both client-side and server-side – just think about all the code that places objects on the HTTP session just so it can be used later on in a JSPX or PHP template;
- it provides a cleaner role segregation than using templates and templating technologies (think Java Servlets and PHP) – this model allows us to have dedicated “web client” developers that churn out beautiful and usable web interfaces using dummy data providers while server-side developers focus on clean and optimized web tier code;
- having a clear and strict API and a decoupled web client allows faster and safer technological improvements on both the client-side and the server-side – imagine building a totally fresh “web client” in a new technology or building a mobile version while being fully assured that server-side code didn’t just spill into client-side code;
- the “web client” decoupling and clear and strict API allows cross-server-side-platform usage of the “web client” – a lot of effort goes into building a good user interface for a product and having a product framework that works on multiple technological stacks is a big differentiator in this fast moving market. Imagine the same product running on a Java stack and a .Net stack with no code generation, conversions, migrations or whatever… just built using the API and two distinct server-side frameworks built following the said API… that would rock. Because you know, the interface is the product.
Anyway, as apps get more and more dynamic and things just tend to naturally head in this way, and because existing stacks and frameworks got better and better at simplifying browser-server AJAX and RPC-like communication I think it’s time to go with the flow and try to crystallize my ideas, at least at a conceptual level.
This is not a model that suits any type of system but most of the systems being produced today can be built using it.
The web client
The reason I’ve been quoting “web client” is pretty straight-forward: what I actually mean is a fully decoupled HTML + JavaScript + XMLHttpRequest application that runs in a browser and connects to a service respecting a clear API. That’s about it. It’s damn simple.
This web client (see, I’m not quoting it anymore) would consume server-side services that:
- define the client configuration – dynamic UI configuration, user preferences, etc.;
- deal with data and perform business processes;
- deal with metadata – data about data – how the data that the client works with is structured;
- deal with meta-metadata – data about data about data – don’t get scared now, it’s just a pompous term that means telling the client how the metadata is constructed. If data is defined by a data model, what does the data model consist of… this kind of thing. We’ll cover it later on.
Besides the services, the actual web client code is also served by the web tier, in a static, unaltered state.
Now, why would we need all this stuff? The simple answer is: we need all this complex stuff to make it easier to develop using this model and to eliminate code duplication as much as we can.
Having all this stuff clear and concise in a strict API greatly improves our chances of building to scale too, allowing us to cache the things that are less likely to change (because we surely know what those things are) along with the static web client.
There’s also another catch. Following this model, we can build specialized components that handle communication and dynamic interface construction and apply different themes and user interface concepts faster.
The web and business tier
Having the client decoupled and using a strict and clear API we can have full liberty in implementing the web tier.
Knowing the protocols and API allows us to build reusable web tier components that handle API requests in just about any technology stack running on any platform
Liberated from server-side code that infects client-side web markup and the HTTP session, we can switch to stateless models so that we can fully employ scaling techniques like transparent load balancing and clustering with no worries.
Having a clear and concise API, protocol and communication model will let the developers focus more and more on the business side of things and less on glue and stitching things together.
The overall picture
Although I try not to think of this in implementation terms – like building a framework, because I really hate building frameworks – I always deviate toward implementation and component diagrams, well, here is one for you, quickly sketched in Excel (the ultimate diagramming tool, BTW).
That’s it for now, hopefully I’ll have more on it soon.
In code – impossible is nothing
“With our thoughts we make the world.”
- Buddha
When I hear a developer whine or comment that something just can’t be done and that he’s going to quit I usually say: “we are developers. we don’t handle real obstacles, the only obstacle is within ourselves. if you can think it, you can build it… it only takes time”. If we are tired I usually throw in a “weak developers stop when they are tired, real developers stop when they finish” and smile.
For most people it works, for others it’s just not enough and me telling them that “we already are what we want to become” only fires them up and focuses their anger on the closest target – me.
My experience taught me that no matter what the problem is, higher focus, structured work and a whole lot of effort will fix it (not might fix it, it will fix it). Even if it takes the whole night or the whole week, even if you have to scrap it and rewrite it from scratch – everything is possible.
So, this is what I’m going to use from now on:
“Impossible is just a big word thrown around by small men who find it easier to live in the world they’ve been given than to explore the power they have to change it. Impossible is not a fact. It’s an opinion. Impossible is not a declaration. It’s a dare. Impossible is potential. Impossible is temporary. Impossible is nothing.”
