Articles tagged 'web'

Eight things to ask before hiring a web developer Sep 2 2013

Hiring a web developer is an important decision, and a good web developer can make all the difference between a successful, on budget, on time project, and one besieged by delays and issues. So we had a think and have come up with some questions to ask to help get the information you need to make a good choice when discussing a potential project with a web developer.

1. Do they have experience in the same area as the app you're looking to build?

You should be able to view case studies or their portfolio on their site, or if not, then they should be able to provide information about the projects they've worked on upon request (or at the very least, references that back up their claims). You should ask for further detail about their work on projects in a similar area or niche as your own, specifically finding out their role on the project, and what value they delivered.

2. Are they fixed cost, or hourly/day rate, and do they have a method for handling and communicating issues that arise?

This needs to fit in with your expectations and your budget, although billing based on value will almost always be better for everyone involved over fixed cost. Find out how they deal with changes in requirements, new features in the middle of development, changes required as a part of business development, as well as unexpected issues with implementation that can crop up.

3. Do they use source control?

They should be using source control throughout development to track and version their changes. If it's an existing codebase, this might be something you need to give them access to, or if you don't already have it, they should offer to set it up.

4. Do they setup a staging or QA system, and deploy regularly from day one to launch day to show progress?

It's no good getting everything delivered in one go, even if it's exactly on the deadline day - for anything but the smallest of projects, it'll require a bit of back and forth in terms of testing and QA, and making sure not just that everything works and is bug-free, but also that everything is optimised for the best user experience.

5. Do they use a project management app to track progress through development?

They should use a tool to define all of the stories/cards that make up the development, and preferably it'd be a web based tool that gives you insight into what is yet to be started, what is currently being worked on, what is finished, and what is delivered ready for testing.

6. Do they do their own automated testing on the code to avoid regressions?

Using a Continuous Integration (CI) server, they should be able to use their automated testing suite to let them know when something breaks elsewhere in the codebase. They should also have tools or metrics available to keep tabs on overall code quality - while somewhat subjective, there are ways and means to find out overall standard metrics that would pick up larger red flags in the code before they become a problem.

7. What experience do they have in deploying and running an application in production, especially with the target traffic you're aiming for?

They should be able to give you an idea of ballpark figures for traffic/usage levels of the projects they've worked on previously, which will give you an idea of whether they've worked on the sort of scale of project that you are estimating for your own app.

8. What do they offer in terms of maintenance after launch, or in terms of handover to internal personnel where applicable?

Are they able to train your own personnel, or help hire personnel for long term maintenance of the app? Do they have examples of documentation they provide for their project that will help with this? In the meantime, are they available to maintain the project after launch, and deal with urgent production issues?

I'm available for freelance work, whether it's for web dev or other projects. Why not get in touch with me today for a free 30 minute consultation where I can get to know your business better?

Comments

Getting started with Rails 2.3.5 Dec 19 2009

This is a tutorial guided towards those who are new to Rails, or those who have not used it since v1.x and who might want a newbie-style refresher. I’ll be working my way through to some more advanced and interesting topics soon, so for those of you who know all of this already, please stay tuned!

I’ve now been using Ruby on Rails for almost four years, and have seen it progress from version to version. In doing so, I’ve kept up with the changes between each version, and the new features that updates have brought to the table.

For newcomers though, the scene is a little different. Much of the information out there pertains to older versions, from really out of date stuff related to Rails 1.2, to things that may or may not still work as expected when talking about Rails 2.0 features.

I figured that even though it will one day be outdated as well, some Rails newbies might well find it useful to have a straightforward, simple up to date getting started guide for Rails 2.3.5. I’m going to do just that, and a few other articles on the Rails basics, before getting into some more advanced stuff. This article will start specifically dealing with setting up an app, before building our first REST resource using scaffolding.

UPDATE: Jeff points out in the comments below that some users may need to install the sqlite3-ruby gem if they haven’t already (assuming this is your first time with Ruby/Rails/rubygems then that might be quite likely!). As Jeff says, to install the gem, run:

sudo gem install sqlite3-ruby

To begin with, let’s install Rails. I’m assuming you have Ruby and RubyGems installed, but if you have issues with the base setup on Mac OS X, then there is an excellent tutorial here. Once you’re all setup, install Rails as follows:

sudo gem install rails

This will install the latest version of Rails, which at the time of writing is 2.3.5. To specifically install version 2.3.5, for example if 2.3.5 is no longer the most recent version, use this instead:

sudo gem install rails -v 2.3.5

If you don’t want to install local ri and RDoc documentation (i.e. you’ll be looking up API docs online, for example), then you can save a little disk space and a bit of time on installation by doing:

sudo gem install rails -v 2.3.5 --no-ri --no-rdoc

That works for any gem installation.

Once it’s installed Rails 2.3.5 and it’s dependencies, it should leave you with the “rails” command available from the terminal. If you already had a previous version installed, you can make sure that you’ve got the right version at your fingertips by running:

rails -v

That should print “Rails 2.3.5” to the console.

Now on to the exciting part; to create an application, it’s as easy as running:

rails <appname>

So for example:

rails my_new_test_app

I’ll be going over a new feature, Rails templates, and how they can speed up your typical Rails application creation process, in a future post. For now, the default application skeleton created by that command will do.

Let’s go ahead and test our new application. Change into the directory for the new app, and fire it up.

cd my_new_test_app

ruby script/server

This will fire up a development server on port 3000 by default, and by visiting

http://localhost:3000

in a browser, you’ll be able to see the app running. You should be greeted with the default Ruby on Rails page.

Let’s do something a little more exciting, and build something interactive. Rails uses some sensible configuration decisions out of the box, and also provides a fair few generators to get you going with some code. We’ll use one of these generators to provide what’s called a “scaffold”, an automatically built representation of an entire resource, giving you everything you need to get something going quickly. In time, the scaffolding will become less useful as you get used to building the resources yourself more quickly to suit your exact requirements - however to get up and running really quickly, it’s a great start.

We’re going to build a basic note resource, allowing the creation, retrieval, update and deletion of notes (these four actions are referred to as CRUD). To scaffold the resource, run:

ruby script/generate scaffold note body:text

This basically is creating a note model with accompanying controller and views, and we’ve also told it that it should have a single column - body, a text field. It will also be given some timestamp columns (created_at, updated_at) which are updated automatically and can be very useful.

Now let’s go ahead and run the command to bring the database up to date with our changes:

rake db:migrate

This will setup the notes table that was created as part of the scaffold. Now if we visit http://localhost:3000/notes, we can see our fully working notes resource in action!

You can play around with creating, updating and deleting notes and see that it all works straight off the bat.

If we revisit http://localhost:3000 though, we still see the landing page. Let’s set it up so that the root of the site displays the notes index page. We need to do a couple of things to make this happen. Firstly, we need to remove that placeholder landing page, so run:

rm public/index.html

However this still leaves you with the following error when accessing your app now:

We now need to tell the application to use the notes resource for the root of the site. Rails routing can be as complex or as simple as you need it. If you open up config/routes.rb, you’ll see that at the top there is the line:

map.resources :notes

This is the line that exposes your notes resource at http://localhost:3000/notes. So how do we hook up the root of the site to hit the index page for the notes resource? We just need to add a single line to the top of our config/routes.rb file. Right below this line:

ActionController::Routing::Routes.draw do |map|

add in the following line:

map.root :controller => :notes, :action => :index

This tells the app that the root URL (/) corresponds to the index action of the notes controller, which is the one responsible for displaying the list of all notes (the same as seen at http://localhost:3000/notes). Now if you reload http://localhost:3000, you’ll see that it shows the same content as http://localhost:3000/notes.

As before, you can play with the notes to see that it all works correctly - it doesn’t look too pretty, and is almost rarely exactly what you want out of the box, but when getting started with Rails it can provide an exciting and quick way to get new things up and running quickly, and to toy around with.

Now that we’ve got a basic, working application running on Rails 2.3.5, we’ll draw this article to a close. In future articles we’ll delve into more detail on some of the configuration choices you can make when setting up your application, some further detail on building out REST resources, testing your application, and some other more advanced stuff.

For a more in depth and lengthy look at getting up and running with Rails, check out the Rails guide for Getting Started with Rails.

As usual, if you have any comments, queries, suggestions or questions about the above, please get in touch!

Comments

The paradoxical web application hypothesis Dec 16 2009

It suddenly dawned on me that something interesting, and in some ways very paradoxical, is occurring with current application trends. Over the last few years, there has been a marked movement towards rich user experiences in web applications - more and more web apps are using Flash and/or AJAX as well as other modern concepts to really make web sites behave and feel truly like first class applications on your computer, with advanced and intricate user experiences. In many cases now web apps have been able to replace their desktop counterparts for a number of users.

Contrast and compare this with the state of mobile development. For years now, wide ranging and patchy HTML support has hampered mobile website development, but the iPhone brings a much more advanced and impressive web browser to the table, and other smartphones such as those running the Android OS now have very full featured browsers too. And yet there doesn’t seem to be much of a focus on advanced mobile web apps. Sure there are some good offerings on the web, and a fair few iPhone optimized sites - but none that as a user you’d lean on in the same way as you might on your computer. Instead, the focus is on native applications, built to service the platform directly - such as the iPhone, or devices running the Android OS, for example. Most platforms are now running app stores that let users search, browse and download apps too, increasing convenience for obtaining native applications.

So why the difference in approach between apps on your computer, and mobile apps? Why do many users now look to advanced web applications instead of native apps where possible on a computer, but when using their mobile, the focus is on native applications?

One of the biggest reasons is probably connectivity. On a desktop computer, many of us now have always-on connections, so we take for granted our web apps always being there. I myself run a fair few different web apps using Fluid, as their own “separate” applications (this includes Google Mail, Google Calendar, Google Reader, Pivotal Tracker and TVCatchup). I always expect them to work, and so I almost treat them like native applications running on my machine, and not on the web. On a mobile of course, while you usually have a connection of some sort (3G, perhaps degrading to Edge or GPRS in certain areas), there still isn’t that complacency when dealing with content you know is being accessed over the air. And in some areas, there is no signal at all, making it almost impossible for many people to completely rely on mobile web applications. Considering the vast majority of applications run fine offline (either they don’t need an online component, or are fine with a sync later approach), it’s easy to see the appeal of offline, native applications on the mobile platform, as opposed to optimized web application offerings.

Interesting though how these two very different viewpoints seem to have come about at almost the same time, and gone in opposite directions to suit user expectations on each platform.

What do you prefer to use on your desktop computer? And how about on your mobile? And where do you see it all going?

Comments

Page 1 of 1 |