pebble {code} blog

Hack Day Live

Thu, 26 Apr 2012 08:19:00 +0100

What a great day. The whole team working on different projects but of the same theme - the team work was fantastic (helped obviously by the numerous table football breaks and bountiful food!).

The projects that emerged from the day were:

Fear the IOC - a bookmarklet to censor webpages of any term or image of which the IOC may take offence.
Data Visualisations - taking some scraped data of past Olympic medals and visualising it with d3.js, a very cool Javascript library.
Location-sensitive Chat Rooms - a service to allow users to gauge the buzz around a particular location, in this case Olympic venues.
Json API for Olympic Data - Json API giving both historical medal data and 2012 schedule data in an easy to consume way.
Web Visions - a node.js app taking streaming data from Twitter, 4Square and others and displaying location specific buzz.

And the winner was… the Json API, written by Alex with help from scrapers Paul and Toby. Awesome. Congratulations Alex.

We are now seeing how best to take these projects forward and make them demonstrable externally - we will keep you up to date!

For blow-by-blow of the day’s action, read on.

—-

20:00 - So, after an super fun day of coding, pairing, sharing, scraping and eating, the team are ready to show and tell. We will eat and then display the results. But in short, a great day.

19:55 - Pizza here. Getting ready for demonstrations.

19:40 - Project 1. Code name Fear the IOC! Published on GitHub. Check out Mark’s handiwork at http://pebblecode.github.com/fear-the-IOC/

19:24 - Only 36 mins left of the hackday now until presentations, pizza and beer (well, we may have already had a couple of beers!). The demonstrations have started and the last few teams are frantically getting their day’s toil presentable. Screenshots and explanations of submissions coming soon.

15:57 - Just over 4 hours to go! Code getting written, committed and shared.

14:22 - More data scrapping from various sources. The geo-loc team making good progress, as is the social team. Data visualisation had hit a bump, but now back on track. IOC fear team already on the write up!

12:40 - Lunch has arrived.

12:30 - IOC fear bookmarklet preview on the Guardian website - ability to block out IOC trademark words or images:

Before…

After!

12:20 - Massive tea round for Toby!

11:55 - Wow, raining outside!

11:35 - Looking at some very interesting data visualisations.

10:55 - Some images from the morning so far:

10:38 - Data feeds pouring in. Teams working well. Duke Ellington on the wireless! This is good fun!

09:30 - Break. Teams have been decided and discussions are flowing. The different teams are hitting the following topics:

Social
Data visualisation
Locational / travel
IOC fear!

Champagne and kudos for the people’s choice team.

09:00 - Ideas flowing.

08:32 - Team getting warmed up for the hard day ahead!

08:20 - Breakfast getting devoured. Ideas being discussed. Kick off is at 08:45. Excited.

07:49 - Office prepped. Food ready (courtesy of Al Desco). Early birds arriving.

Open data for London and the Olympics

Wed, 25 Apr 2012 17:17:00 +0100

Tomorrow pebble {code} will host our first hackday! The theme is Olympics! The IOC data is distinctly not open but there are some good feeds available.

Food for developers

Who needs coffee, pizza and beer. We need data!

Some examples of what you might do with these are at MapTube.

Have more good links for Open London data? Post them in the comments.

Sending usage stats to Campfire

Mon, 23 Apr 2012 11:08:00 +0100

Automate all the things

We use Campfire heavily at pebble {code}. After a brief flirtation with IRC we found it was the easiest way to get everyone in the team involved. We post quite a few things to Campfire:

Git commits from GitHub
Git commits from local, private repositories
Build notifications from Jenkins
A few things from Marvin, our hubot.

As everyone is in Campfire is makes lots of sense for us to do this. We don’t waste time having to ask people in the team what they are doing since it is all there.

How are our apps doing?

We have recently created a couple of web applications in Tricklr and Vistazo. Every now and again people ask ‘How many users do we have?’ or ‘How many projects are there’. Typically questions like this result in

SSHing into the server
Logging into PostgreSQL
Running some queries
Pasting the results into Campfire

About the fourth time of doing this it became obvious this is a job for automation!

First pass

A first pass at this resulted in a quick rake task after about 20 minutes from start to deploy. The rake task uses tinder a neat little gem for interacting with Campfire from Ruby.

task "campfire:stats" => :environment do
  campfire = Tinder::Campfire.new '[YOUR_ACCOUNT_NAME]', :token => '[YOUR_TOKEN]'
  room = campfire.find_room_by_id([YOUR_ROOM_ID])
  # Get the data you want with ActiveRecord
  users = User.count
  room.speak "OHAI! Stats from YOUR APP"
  room.paste "Users: #{users}"
end

For a quick and dirty solution not bad. This is added to a cron job run on the server at 9.30 each day, just after everyone gets/logs in.

Feature requests

Some things that would be good to have:

Comparison with yesterday, last week and the month before.
Make it a Marvin script! This would allow Marvin to tell anyone how the apps were doing on request.
Package it up as a Node.js module or gem

Vistazo: The making of our new baby

Fri, 20 Apr 2012 14:40:33 +0100

We publicly released Vistazo recently - a web app to view and manage a team’s schedule - and now it’s time to take a step back and do some reflection upon the story of our new little Pebble Code baby.

It was a natural and organic growth, and it started with the conception of the idea…

Conception

Vistazo started off as a scratch-our-own-itch type product, when we were struggling to find a simple application that would let us easily keep track of what everyone was working on through the week. We alternated between several different solutions (basecamp, github, pivotal, trello and even a google spreadsheet), and while they were all great products, they weren’t what we wanted here at Pebble Code. Some felt overkill, some felt overly complicated, and some were just clunky to get things done.

That’s when we were incepted with this idea - Hey! We build stuff! We can build this thing ourselves! It’s a simple enough problem to do with a small team, and we can build it to exactly how we want. It’d also be a very nice learning experience for Pebble Code.

Business time

Vistazo is very much a design driven product, focused primarily on simplicity. We also like the philosophy of do one thing and do it well, which Vistazo strives for in the space of team scheduling.

Development started with wireframes and design of the interactions, to get an idea of how it would work before we coded it all up.

Having the initial designs and some html mockups, along with choosing some lean technologies, Mark, our resident designer, and I were able to create a usable prototype within a week. This v0.1.0 release had most of what we needed internally, with the ability to view weekly schedules, create projects, and add/remove/drag and drop timetable items. Woot! It was a fun bit of work, and not much of an investment at all.

Gestation

Although Vistazo was usable after this 1 week prototype, we felt there was still a lot of opportunity for it to grow, and more we could do with it. So we decided to carry on with our designer-developer duo setup (with great support from the rest of the team along the way) and iterate on 1-2 week sprints to refine the app, and also generalise it to be useful for people outside of Pebble Code.

Pebble IT, our sister company, was one of our first guinea pigs to test the software. From their use, we realised that we needed the idea of teams, to allow people to be in more than one team and view different schedules.

An obvious type of feature in a team scheduling app, but we kept to our simplicity philosophy and only added it when we needed to. Keeping things simple helped to manage scope creep, and especially for such a small team, it was necessary to keep things realistically doable.

Bump!

Feedback is such an invaluable thing during the development process. It’s very easy to get stuck in your own head when creating something, and watching other people use your product is one of the best ways to find things you missed.

Amongst the development sprints, there was a dedicated sprint to user testing. We used Silverback and a questionnaire on a handful of users for this. Silverback was a useful tool to see exactly how people were navigating the site, and seeing how they reacted to the different tasks. It helps so much, just being able to see people’s faces and hear what problems they encounter as they are using the app.

Also, a more simple method, requiring less effort was just to push the code to a server, send an email out to the office and ask for feedback. The latter shouldn’t be dismissed either, as it was equally as valuable.

All this feedback helped to find usability bugs, give us insight to what people thought of the app and helped find out where we should direct our attention for new features. Project view and month view came from these feedback sessions, and they’re some of our proudest features.

Pop! Out she comes!

It was a clean and safe birth, with all parties coming out unscathed… and now Vistazo is available to the world! =)

It was great fun making Vistazo, playing around with new technologies and learning a whole bunch about product development along the way. Please, have a play with the new kiddo, and if you have any feedback or suggestions, send them our way at vistazo@pebblecode.com. Enjoy!

Vistazo goes live!

Wed, 11 Apr 2012 14:58:05 +0100

Today we are proud to release our latest bouncing baby to the public.

Vistazo is a lightweight web application to help small teams keep track of who is working on what and when they are working on it.

We created Vistazo to solve a problem we were having at the pebble {code} office with keeping track of what everyone was working on. We found the available solutions for team/time management were far too complex for our needs, often adding in a ton of functionality that we really didn’t need. Just like any other great software company when we discovered the right tool for us didn’t exist, we decided to build our own.

We’ve been using (and loving) Vistazo internally for a few months and now we’re at a stage where we’re happy to share it with the public.

Vist vistazoapp.com to try it out for yourself.

Any feedback you have about it is greatly received, so please get in touch if you have any issues, would like to request a feature, or preferably just to tell us how much you love Vistazo!

Budget 2012 and us

Fri, 23 Mar 2012 09:25:29 +0000

Let’s frame where we are coming from - pebble {code} is a software company with (much) less than £50M turnover and less than £300K profit…

What does this mean for us?

Well, for now, Corporation Tax will remain at 20% - fine. However, if you are a business with greater than £300K profit, you are down to 24%, from 26% - good.

There is good news for us software developers if we have patents - Patent Box says that profits made from patents will only be charged at 10% Corporation Tax - good.

No reduction in business rates - bad. Instead they will go ahead with a rise to 5.6% - grr. There is also no reduction on fuel tax - not a biggy for us, but still - bad.

In terms of cash, a number of banks have signed up to the National Loan Guarantee Scheme that will have banks lending at 1% lower rates than those outside of the scheme for businesses with less than £50M turnover - this is good if you are able get a loan approved in the first place!

So, that is a very quick round up of what that Government’s Budget 2012 has meant for us as a small business. Not lots of good news, but not dreadful.

There is however another very interesting Government scheme that has come to our attention recently - SEIS or Seed Enterprise Investment Scheme. In a nutshell it offers massive tax breaks for investors wanting to invest in startups. Rightly so, the chancellor sees us small businesses as the life blood of the economy. Boom!

Will it blend?

Mon, 19 Mar 2012 13:51:00 +0000

Yes!

Recently I’ve been experimenting with Illustrator’s blend tool. After a little trial and error I’ve developed a few tricks for producing interesting gradient-based effects with the specified steps setting. Now that I’m pretty comfortable with the techniques I’ve developed I thought it was time to share.

First let have a look at how the blend tool works.

Start by drawing two parallel lines. It doesn’t mater how you style these lines. Just make sure that the lines are parallel and (for now) they have the same style.

Next go to the top menu : object > blend > blend options. Select specified steps for spacing. Input 8 for the number of spaces. And select “align to path” from the two buttons.

Next go to the top menu : object > blend > make. You can see illustrator has rendered us some more lines between the two we started with.

Larger numbers in the specified steps field give you more lines, lower numbers less. Simples. This is essentially how the blend to works with specified steps.

Now things get interesting. Blending two paths with either different thicknesses or colours will (yeah you guessed it) blends between the two values.

We don’t just have to use simple paths, we can use shapes / grouped objects as well.

Any (vector) effects you have on the paths will also be blended. Here we have zig-zag (smooth), roughen, and scribble.

We can combine all these elements to make some pretty strange visuals. This is an example of a thin blue line with the roughen effect applied blended with a fat pink line with the zig-zag effect applied.

Now we can use this technique to create a thousand different type of visuals. We can make ordered patterns, psychedelic abstract compositions, and even use it to create (relatively) subtle type treatments.

If you have any questions or if you’ve used this technique to create something, please let us know in the comments. Above all, have fun with it. The blend tool is my current favorite vector tool because it lets you experiment easily and sometimes gives you results you just weren’t expecting.

Dump the big 6

Mon, 27 Feb 2012 09:19:09 +0000

Here at pebble {code} we have our heads firmly out of the sand. We believe in climate change and that as a responsible company we should be doing everything in our power to mitigate it’s effects. That’s why we’re proud to shout about being a customer of Ecotricty. Their new campaign to “Dump the Big Six” strikes a chord here at pebble - there’s literally no reason not to switch your energy company today, away from one of the big 6, to a cleaner, greener supplier.

If you plan to switch wither your home or business to Ecotricity, see the details here on how to make a donation to our favourite green campaigning charity at the same time.

George talks Node.js

Wed, 15 Feb 2012 11:50:00 +0000

Our Creative Director, George (@shapeshed), took to the stage on Monday night to give a talk on Node.js. The event was hosted by Forward who gave us free beer and pizza - thank you Forward!

An Introduction to Node.js from London Web Standards on Vimeo.

The evening was a great success - as we heard from numerous people afterwards - and it was great to hear from a few companies that are already creating successful applications using Node.js.

George is also writing a book on the subject, titled ‘Sam’s Teach Yourself Node.js in 24 Hours’. It is due for release later this year and you can pre-order on Amazon.

For more information and to get involved, check out ‘lnug’ (London Node User Group), also hosted by Forward - next meetup next Wednesday 22nd February! (as we were told just a few times).

Styling for Tricklr 1.0

Tue, 17 Jan 2012 17:52:00 +0000

Tricklr’s previous UI was developed ‘old school’ - the design was mocked up in Photoshop, all the relevant images were ripped and then the styling was approximated in css.

When we started the redesign, we decided to to try a new approach to the design and implementation. Here’s a run down of what we did and why we think the new approach was a success.

We started off by creating a separate style guide that could be applied to all of the elements in the app. To start, we created a simple .html doc containing all the elements we needed to style. We tried to give all elements class names that were as generic as possible (about 60% of the elements have the class button).

The blank .html doc ready to get beautiful.

With this blank canvas ready, we started to style each element. Most of the styling was done ‘in browser’ using css3 goodness, but there was also quite a lot of Photoshop / Illustrator work done at this stage for things like the tiling background and working out colours for gradients.

The style guide with css/images all linked up.

We also made a folder of tiling noise .pngs of different opacities - this let us add different amounts of noise to different elements without having to keep going back and forth between css and Photoshop each time. If you’d like to use the same set up for your designs you can download it here.

Once happy with the style guide, we (the developers) started adding the styles to the app. We used compass to handle all the vendor prefixes which made dealing with all the nice css3 stuff that much easier.

After all the styles were in the app we found a few small bugs and made some tweaks here and there, mostly to do with positioning rather than style.

Now you might be asking yourself why bother with creating a style guide when you could just style the app in browser and have the same effect? Here are a few reasons why we think it’s worth adding that extra step:

When your not worried about anything linking up or having any functionality you can focus purely on the UI.
Separating design elements from the app as a whole helped us keep similar elements consistent.
Designers can work on the UI whilst developers work on functionality without getting in each others way.
You can see all the elements for the entire app on one page rather than having to switch pages to check out what’s what. This also lets you see how the UI works as a whole rather than for each page.

Overall it’s probably slightly more time consuming to do things this way but you get a better result. The design we ended up with really succeeds because everything with the UI is coherent and that’s a direct result of taking the time to design the style guide.

Tricklr 1.0

Fri, 13 Jan 2012 16:11:23 +0000

We have finally found the time to release Tricklr - an app we have had in the works for a while.

Tricklr solves the annoying problem of being continuously active on Twitter without having to stop 10 times a day to think about writing a tweet. Now, you can write lots of tweets in a oner and they will just trickl out at a pace you set.

Tricklr is a very simple app and we hope that you like it! There are a couple of screenshots below, but probably best to just go and try it out!

The Tricklr Queue

The Tricklr Settings

Try Tricklr at tricklrapp.com and please let us have any feedback on our GetSatisfaction page.

Enjoy!

Creating possible combinations from a list of lists in F#

Fri, 13 Jan 2012 09:59:35 +0000

Just a short post after I came across an interesting problem while learning F# and couldn’t find any great resources to solve what seems to be quite a generic problem.

The scenario is:

You have a list of lists where each of the inner lists contains 1 or more element.
You want to find all possible combinations where you take precisely one element from each inner list.

The example of where I found this problem is calculating the possible value of a hand in blackjack:

You have a set of cards
Each card has a value
Ace has both the value 1 and 11 at the same time
You might be holding more than 1 ace

Therefore we want to be able to calculate the possible values the card could be determined to have.

We represent the value of each card as a list. The five of hearts is [5], the jack of clubs is [10], and the ace of spades is [1;11]. If you hold all three of these cards in your hand you can either make 16 or 26.

We would represent this hand as [[5];[10];[1;11]] and would ultimately aim to get our results in the form [16;26]. However as an intermediate step we want to transform our hand into a list of possible card values such as [[5;10;1];[5;10;11]] which we can then simply sum to get our result.

Here’s the function that recursively expands all combinations, returning a list of each combination of items.

let rec combinations (l) =
    match l with
    | [] -> []
    | h::[] -> h |> List.map (fun opt -> [opt])
    | h::t ->
        combinations t
        |> List.map (fun tOpts ->
            h |> List.map (fun hOpt -> hOpt ::tOpts)) 
        |> List.concat

Essentially, a quick line by line run through is:

To cover all cases, if this is called with an empty list, just return an empty list. This is not used in the recursion.
If we are looking at the last list of options then return each option as a new list containing only itself.
If we are in the middle of the list (or equally the start) then get the combinations of the tail option lists giving us a list of combinations.
For each combination,:
1. For each option in the current set of options
  1. Add the option to the beginning of each of the tail combinations
Flatten the list of tail combinations of head options to outcome list to a list of outcome lists.

Hack Day Paris

Tue, 08 Nov 2011 09:26:52 +0000

Two member of our web team, Tak and Vince spent the weekend in Paris to take part in the Paris Hack Day. Sounds like it was a fantastic event, and together with their 3 team mates, their innovative categorised free goods recycling scheme won the social prize at the event, well done guys! The demo of their app, freesbee can be found here

http://hackdayparis.soey.me.uk/

Full write up coming soon…

Getting a startup off the ground

Tue, 18 Oct 2011 10:28:44 +0100

Following the yellow brick road

Photo by Chris Devers

Recently at pebble we’ve had a lot of discussion about the best way to get a startup off the ground. We have the ideas and the skills but need a coherent way to make it happen. We’ve got a mixed team of designers, developers and business level people all of whom have different skills and different ideas on the right way forward.

Here are the options as we see it and the relative pros and cons.

Use client work to fund the startup

This model works where the team works on client projects in order to fund the time to work on the startup. The profit from the client work pays salaries and any fat is pooled into a fund to support working on the startup project.

Pros

No external or personal investment is required

Cons

Lead time before the fund is big enough and the project can start.
Will end up working on the project in fits and starts.
Client work never ends!

Hack days

Come into the office at weekends to work on the startup. Given the short amount of time available it is felt more work will get done and the project will progress further.

Pros

Everyone is available at the same time

Cons

This isn’t great for life outside of work and needs an understanding family/partner
Very short amount of time to work on the project

Spare time

This essentially asks members of the team to work on the project for free in their spare time. Particularly for designers and developers this can be a significant amount of time.

Pros

If you can find a willing developer this is a great option as it doesn’t affect cashflow or client business.

Cons

Pressure on personal life.
No guarantee that you’ll actually see a return on the investment of your time.
Risk of developer burn out.
Working in fits and starts.

Venture Capital Investment

Go into the market and see if an idea can get investment.

Pros

The project will be funded properly so a team can be resourced properly.
Dedicated time to the project
Bad ideas will quickly be shown to be bad ideas
No need to continue client work

Cons

Need to give a significant part of the business away
Very competitive

Personal Investment

Members of the project team put up their own cash in order to fund a project.

Pros

Able to resource a project properly
Full ownership of the business

Cons

Personal money at stake
Further rounds of investment likely to be required

Develop something for a client then spin it off

This model means developing a product for a client and then extracting it into a web application. There are issues over intellectual property here but if these can be resolved this is a great option.

Pros

You have an active client to help scope the product
You get paid for it
The development costs are largely covered by the client

Cons

The product may end up being too specific to the client
Intellectual property issues

Conclusion

The biggest issue in all of this is funding. We have the skills and the ideas but we also have mortgages and families. None of the options are 100% perfect and the one we’ll choose won’t necessarily be the right one for all situations.

Ultimately this situation is no different from normal business rules and getting a business off the ground. It is about risk and return. Some options are safer and take longer to achieve, whilst others are more risky but resolve the situation more quickly.

So take your pick Dorothy.

Fetching and caching Google Calendar data in Rails

Tue, 18 Oct 2011 10:28:35 +0100

Recently we had a requirement to show Google Calendar data for a client on a Rails intranet project. The requirements were a bit outside what’s offered by the embedded iFrame option so we needed a better solution to retrieve Google calendar data.

Options for getting data from Google Calendar

The simplest option is just to use the iFrame that Google provide that is accessible from your Google Calendar under Settings > Calendars > Name of your Calendar > Embed This Calendar. You don’t really get to customise this though so what you see is what you get

If you want the raw data so you can do things with it Google publish the gdata-ruby-util Ruby library which provides an interface into Google’s Data APIs. This is a very useful gem, providing full access to lots of data across Google services. From a Ruby perspective it seemed like you need to write a lot of code for a simple API call.

Better for our requirments was the GCal4Ruby gem that provides a clean interface to Google Calendar data. It works for both Google and Hosted Accounts and with just six lines of ruby you can get event data for a particular calendar:

service = GCal4Ruby::Service.new

service.authenticate("USERNAME", "PASSWORD")
cal = GCal4Ruby::Calendar.find(
    service, 
    'YOUR_CALENDAR',
    {:scope => :first}
)
events = GCal4Ruby::Event.find(
    cal, 
    "", 
    {
     :range => {:start => Time.parse("08/04/2000"), 
     :end => Time.parse("09/04/2010")}
    }
)

Once you’ve got the data you can iterate over it as you want

for event in events
    #do stuff here
    puts event.title 
end

Caching

The API call takes a while to come back so we don’t really want the user experience to be impacted by slow load times. We can use Rails caching to store the response and only fetch it when we need to. We put this into a rake task so that we could call it using a cron script to keep the calendar up to date

task :gcal_update  => :environment do
    Rails.cache.delete('gcal_events')
    Rails.cache.fetch('gcal_events') {
    gservice = GCal4Ruby::Service.new
    gservice.authenticate("USERNAME", "PASSWORD")
    calendar = GCal4Ruby::Calendar.find(gservice, 'your calendar',  {:scope => :first})
    events = GCal4Ruby::Event.find(calendar, "", {
        :range => {:start => Time.now.beginning_of_day, :end => Time.now.advance(:days => 7)}, 
        :singleevents => true, 
        :max_results => 1000, 
        :sortorder => "ascending" })
        upcoming_events = {}
        # We're saving the next 7 days of events
        days = Date.today..Date.today.advance(:days => 7)
        # initialize the hash
        days.each{ |day| upcoming_events["#{day.to_s}"] = [] 
    }
    events.each do |e|
        # should find out if its an all day event or a recurring event. 
        event = Hash.from_xml(e.to_xml)["entry"]
        days.each do |day|
            current_event = {}
            if (event["when"]["startTime"].to_date <= day) and (event["when"]["endTime"].to_date >= day)
                # save useful data into a hash
                current_event["all_day"] ||= event["when"]["startTime"].to_time.to_date < event["when"]["endTime"].to_time.to_date ? true : false
                current_event["title"] = event["title"]
                current_event["uri"] = event["link"][0]["href"]
                current_event["time"] = event["when"]["startTime"].to_time.strftime('%H:%M') if event["when"]["startTime"].to_date == event["when"]["endTime"].to_date
                upcoming_events["#{day.to_s}"].push(current_event)
            end
        end
    end
  upcoming_events
}
end

Showing the calendar

Now in our controller we have an easy way to get the latest calendar data and we can then loop over it in our view

@calendar = Rails.cache.read('gcal_events')

You are the designer

Tue, 18 Oct 2011 10:28:27 +0100

New websites and tools for browsers are showing that users have more control over design than ever.

With the release of Safari 5 Apple added a Reader feature that takes a web page and formats it for easy reading. This type of feature has been around for a while in Chrome and Firefox via the Readability Extension (Chrome & Firefox) and gives users the option to reformat the page in a more readable format. Here’s the pebble blog reformated using Readability.

At pebble we’ve really been enjoying using these tools to get rid of unnecessary navigation and adverts, and correct poor typography.

What do websites need to be able to take advantage of this? Not much - providing you have used well-formed HTML your web pages will be neatly formatted by these extensions.

APIs also free content from design

Another project that caught our eye this week was the reformatted Guardian site created by Phil Gyford. This takes content from the Guardian API and reformats it for easy reading. We have found it works particularly well on the iPad and is a great example of how publishing your content via an API can give it new contexts without any effort from the creators of the content.

Where does this leave the designer?

We are the first to admit the importance of UI design but these examples show that, like it or not, you the user will have greater control over how content looks. Browsers are offering users more options to assign custom styles, turn parts of the page on and off or to change the layout entirely.

In our opinion this is a good thing. The web should be open and users should be able to choose how content appears.

And.. don’t change our reader

Shortly after the Safari 5 feature several users began publishing custom styles for the Reader page allowing Safari users to change the way the reader page looked and Apple had intended.

This provoked unhappiness from Apple employees including Faruk Ateş who wrote:

Don’t risk unwitting users’ safety or their user experience with your hacking suggestions.

I’ll leave you to mull on the irony of that.

Using the browser to customise web pages will become more popular so expect designers to throw their toys out of their prams and users to rejoice that they can view pages how they want to.

pebble.it on github

Tue, 18 Oct 2011 10:28:18 +0100

The dev team at pebble.it are proud to announce that we finally have a home on github!

When we started the development arm of the business we stated that being an active member of open source projects was one our goals. We also have a lot of things that we think would be useful to others. We have used many, many open source projects in our work so it is high time we started to give back.

Having a public account will allow us to publish our work and hopefully learn from others in the process. We have plans to publish things like our default Rails app, ruby scripts, puppet configuration, some work we’ve been doing in F#, our default CSS framework as well as miscellaneous shell scripts.

Hurray!

Titanium - native mobile apps with JavaScript

Tue, 18 Oct 2011 10:28:12 +0100

At pebble.it the development team have been working hard to get up to speed with iOS so that we can support our clients’ growing requirements for mobile applications.

The team have reached a good level of understanding on iOS even diving into OpenGL to create a complex drawing application.

With most of the team coming from a web background we’ve been keeping a close eye on frameworks like Phonegap and Titanium.

Inspired by the wonderful wunderlist, which is built on Titanium, we had a closer look at Titanium.

One API to rule them all

One issue we’ve discussed as a team is the fact that in developing mobile apps there are multiple SDKs and frameworks to master. Just as soon as you’ve got to grips with Objective-C and the iPhone SDK there’s Android and Blackberry. To date our philosophy has been let’s get really good at iOS. We are still following that but Titanium allows us to support other platforms, at least on a superficial level.

Here’s some code from the default scaffolding app. If you are familiar with JavaScript it should read easily to you.

//
// create base UI tab and root window
//
var win1 = Titanium.UI.createWindow({  
    title:'Window 1',
    backgroundColor:'#fff'
});
var tab1 = Titanium.UI.createTab({  
    icon:'KS_nav_views.png',
    title:'Foo!',
    window:win1
});

var label1 = Titanium.UI.createLabel({
    color:'#999',
    text:'I am window 1',
    font:{fontSize:20,fontFamily:'Helvetica Neue'},
    textAlign:'center',
    width:'auto'
});

This is the code behind creating a tabbed window with a label for both iOS and Android:

For more checkout the API documentation and Code Examples.

Strengths

Titanium has surprisingly good coverage of the APIs for iOS and Android. Installing the KitchenSink application on a device shows just what you can do with it.

It is quickly apparent that it would be possible to scaffold an application for both Android and iOS in no time.

The fact that Titanium creates native applications using just JavaScript is a huge draw.

Weaknesses

Installation didn’t go smoothly, leading me to the forums where I found lots of other developers who were having problems getting Titanium off the ground. I followed the advice of a couple of posts, fixing a bug in the Python source, and had to fiddle around with a number of things on Android to get it working.

Documentation and walkthroughs are a little light and I ended up learning from the source. Some might argue that this is the best way to learn anyway but it would be great to have some more code examples in the API documentation. Given that this is an Open Source project if we use Titanium I’d certainly be willing to fork the project and improve documentation. There are also paid for videos available.

Issues like memory management and how Titanium performs across different versions of SDKs are not really understood at the moment.

Conclusion

Titanium looks like a really interesting project for our business. Given that we can also use it to write cross-platform desktop applications it actually opens up new markets for us. It leverages existing skill sets within the team and will allow us to get apps off the ground more quickly. For more complex client requirements though we will need to drop down to writing custom code - a common scenario with frameworks.

Our New Office

Tue, 18 Oct 2011 10:28:03 +0100

A few months back, we moved into a bigger and better space. It has been a really fantastic move for us and we love it! We are still in Vauxhall and all very happy.

Here are a couple of pics to give you a flavour - if you’re in the area, why not drop by for a cup tea and a biscuit?!

Luv,
pebble {code}

Our fun wall, by the Graffiti Kings:

One corner of the room:

And, the as yet unfinished meeting room (with cinema and dart board!):

Green League 2011

Tue, 18 Oct 2011 10:27:55 +0100

We’re super excited to finally be able to announce that we’ve been working on an iPhone app over the last month or so, in collaboration with our favourite environment organisation, People & Planet. People and Planet is the largest student network in Britain campaigning to end world poverty, defend human rights and protect the environment. The award-winning People & Planet Green League is the only ranking of UK universities by environmental and ethical performance. This year 142 unis took part, and the results were released in today’s Guardian newspaper. We think it’s a great project, providing prospective and current uni students with a tool to demand and justify change in their unis. Download it now and give it a whirl.

The app, whipped up by our in house iPhone wizz Tak, provides university search and comparison features. For those students applying through UCAS for the next academic year, this app provides a really neat way to compare uni choices on a sustainability basis, allowing students to checkup on their uni’s ethical & environmental performance in a number of fields, whilst on the move. Hopefully it’ll lead to a few awkward questions on campus tours too - there’s nothing like customer pressure to drive change!

The app is available for download now on the app store.