Taking some time to think about how people will be using your admin system and planning accordingly will save everyone a lot of headaches down the line;
For me there are other benefits to making the admin systems a lot nicer; in web development we spend a lot of our time having to make sure things are cross browser compatible, which can often mean not exploring the latest technologies or ideas, or making things as slick and funky as we’d like, because some browsers don’t support the features we’d need. With admin systems we can often have a bit more say in what browsers people should be using, so we can restrict them to modern, up to date browsers, giving us the opportunity to try out some cool stuff that’s going to make things much more interesting for both them and us.
Another thing often overlooked is the usefulness of colour. Colour coding information and buttons can give a much quicker visual clue than any label, allowing an end user to gain a broad overview of the information being displayed, just with a glance. This can also help with making the system more intuitive; green buttons for positive actions, red buttons for negative etc.
So next time you’re building a backend for a site you’re working on, or just any form of control panel. Stop and think about the end user. If possible ask them about how they would ideally want it to work, treat it like you would the design and developement of the front end and get user feedback throughout the process. Do all this (and act upon it) and you’ll end up with much happier end users, even if the end user is you.
]]>At the moment the app is a very basic read only affair as Coderwall’s API is read only, but I know they have plans to expand on the API, particularly to enable access to some of the new features they are adding to the main site, and as they do I’ll be updating the app to take advantage of those.
The app is free to download for both iPhone and iPad, and also the source is available on GitHub for anyone wanting to take a look and use it to help them get started in app development. The app was very much a learning exercise for me, which is why I’ve made it free to download and open sourced it, in the hope that the lessons I’ve learned will benefit someone else.
Also if you have any issues, or feature requests, you can use GitHub to tell me about them, or even submit a pull request for them.
There will be a Windows Phone version released, hopefully, in the next few months, will post more about that when it is released, and once I’ve got that out of the way I’m going to be looking at adding more functionality to both apps, so watch this space!
I’d like to say a big thanks to the guys at Coderwall, particularly Matt, who have been really helpful and supportive of me while I’ve been building this app, particularly in making extra information available to me via the API and in offering to add more functionality so we can make the app even better. Thanks very much guys, hope you like it!
]]>Guggenheim.js is a framework agnostic plugin for your website that will create an animatable gallery. It currently supports animated filtering and reordering of the galler items, as well as the pre-requisite pagination. It makes use of absolute positioning and hiding the overflow to position each item in the right row and column so that they remain in the correct order but still inside the same container. This enables me to animate the items to their new position when filtering or re-ordering, giving a really cool looking effect.
The animation is using the same code I used on tipBox, but with improvements and fixes that I will eventually port back across. It will use CSS3 animations where available but fallback to Javascript when necessary. The javascript animation is using a modified embedded version of emile with Kangax’s fixes to make it play nicely with opacity in IE8. This gives it a nice, lightweight engine for handling the animation.
I am intending to add functionality to auto generate pagination links, including numbered pagination, but for now you can easily add your own prev and next buttons and call the exposed methods of the guggenheim object.
Check out the Source Code and Examples over on GitHub for more information:
]]>Firstly, why the move? Well for one thing having done some work on setting up custom Wordpress sites for people recently I have massively fallen out of love with it. Don’t get me wrong, for the layperson who wants a basic blog it’s great. But for me it just wasn’t working out. There was also the fact that it was costing me for hosting and I wanted some cheap decent hosting. Enter Octopress, I’d seen some information on this a couple of times but never really properly looked at it, until now. For those that haven’t heard of it, Octopress is a blogging framework designed with hackers/coders in mind. It’s built on top of Jekyll the blog-aware static site generator that is used by GitHub pages. The way it works is that you create your posts in Markdown or HTML files, then run a Rake task which then builds static pages with your content on them. What this means is no database requirements, and technically no server side language required. This meant I had the choice of 2 (that I knew of) possible hosting options, GitHub Pages or Heroku. Both seemed like good options, both were free, had good levels of support and service, and would let me use custom domains. In the end I decided to go with Heroku as I’d been wanting to try them out for a while and it gives me a good scalability, so while it’s free for now, I can add more to it if I need to. So far this seems to be working out pretty well for me and I’ve since started hosting another project that I’m working on with them. As for Octopress, I’m really happy with that and would thoroughly recommend it to anyone needing a simple blogging solution.
As for the new job, well I’m now working at a games company called Eutechnyx in Gateshead. I’m one of the main Web Developers working on their new Online Racing MMO Auto Club Revolution. This has been a big change for me as it’s meant leaving behind PHP and MySQL and embracing Python and MongoDB. I’ve also had to get to grips with SVN which has been a considerably less enjoyable process. As for Python and Mongo I’m really enjoying them. Python is still a strange language to adapt to with it’s whitespace orientated style, thankfully the time I’ve spent using CoffeeScript lately has probably helped a great deal with that. I’ve also been using Mongo on a private project I’m working on with Ruby and Sinatra and finding that really snappy easy to work with once you understand the way embedding documents works.
So what does the future hold for me? Well I think that for now I’m leaving PHP and MySQL behind. I’m still going to be continuing in my Javascript development and looking to bring CoffeeScript into that as much as possible but my server side work is now going to be either Python or Ruby, both of which I’m having a lot of fun with at the moment. As for my choice of data storage? I think it’s safe to say MongoDB is here to stay on that front, although I will miss working out clever SQL queries.
]]>I’ve been trying to find a nice simple solution for setting up my project skeletons quickly and easily. I’d thought of some sort of Git repository but then I’d end up with some faffy process involving multiple branches for different project types and having to clone a repository and then remove the git repository in the newly cloned folder and well, this didn’t sound quick or easy. Eventually I hit on the idea of a command line ruby gem that could use templates defining a directory structure to set up what I needed. A quick search turned up nothing that seemed to do the job, the closest thing was Mr Bones but that seemed to be entirely for Ruby projects and the template skeleton wasn’t easily customisable. I was disappointed that it existed though as I wanted to name my gem bones but hey, how many things am I going to write that I can actually justify calling Skeletor?
So I started looking into what was involved in creating ruby gems. Initially I started of using Jeweler but this created a lot of stuff I didn’t really understand so I decided to strip everything back and just look at the structure of some gems I already used. My main source of reference was Sprockets but I also used Capistrano when trying to understand the command line aspect of the gem. These gave me a good source of reference for what was required in the various gem files.
For anyone who’s not created gemfiles before the basic folder structure is as follows:
I’m not going to go into the details of each of those files. I’d say the best thing to do is to check out the source of some of the gems that you use and that will probably give you the best understanding of what’s required. I’m using Thor for the command line interface and Hike to locate the files in the 2 possible load paths.
Skeletor supports defining a directory structure with files and folders. You can also specify include files which will be copied into the directory, either from a local file or a remote url, and define build tasks to be run after the directory is set up.
The code for Skeletor is actually pretty simple. Ruby’s built in YAML.load function converts the template file into a Ruby Hash object which can then be looped through and there is a JSON gem that works in the same way. The most complicated part was the validation code as I needed to be able to specify custom data types that a node could match any one of. The only gem I could find for YAML validation was Kwalify but that wasn’t flexible enough for what I needed so I had to write my own. I eventually managed to get a working validation class that worked for what I wanted and decided to extract it into it’s own gem so it could be used for other projects, and thus Grayskull was born.
Grayskull will validate JSON and YAML files against a given schema including matching against custom types. All the details for how to create the schema are at the GitHub page, as are the instructions on how to install and use it. The same goes for Skeletor. Grayskull is also using Thor for the command line as well as the aforementioned JSON gem for validation.
Check out the GitHub repositories for the source code and instructions.
]]>So far the following have been updated:
Obscura - Examples | Documentation
Uncharted - Examples | Documentation
Ermintrude - Examples | Documentation
tipBox - Examples | Documentation
So what do I think of Objective-C? Well I’m still in my early stages of playing with the language so this is really just a first impression but I think I’m going to like developing in it, and I certainly think I’m going to find it easier and more enjoyable than I ever did Java. It’s very different from most of the languages I’ve ever learned and certainly a huge change from the languages I use on a daily basis (PHP and Javascript). One of the first things I’ve noticed is how verbose it is. There is very much a convention of the code reading like plain english, with things such as long variable names and methods. The way methods are defined is one of the primary examples I would give of this verbosity, and of the difference of Objective-C to languages I’m used to. The following examples show a comparison of how methods are defined in Actionscript 3 (I know, I know, but it’s the only langauge I know well enough to write comparison code in that defines the return and argument types) and Objective-C.
As you can see the single argument methods are pretty straight forward, return type at the start, followed by the method name, then the argument and it’s type listed after a semi colon (felt weird having no brackets). From what I’ve seen there doesn’t seem to be any indication of public or private with the method definitions. What seems to happen is that you just don’t define methods you want to be private in your header file, which defines the class’ public api. The - at the start of the definition indicates that this is an instance method, a + indicates a static method. The primary difference in the way methods are defined is when it comes to methods with multiple arguments, where you see this splitting of the method name. The only real purpose I can see of this is that if you write your method names and variables properly it helps the code read like plain english.
As for developing in XCode, so far I’m liking it. The built-in Interface Builder Gui tools are really helpful, especially when it comes to linking the controller to your views. It’s taking me a little while to find everything in the property inspectors, possibly because what I’m looking for isn’t available for customisation but you never know. The in-line error and warning highlighting is really helpful as it makes it much easier to see where you’ve missed that semi-colon or curly brace. I think I’m really going to like the property synthesization (more on that once I’ve gone more in-depth with it) that allows the compiler to auto generate methods for you.
Developing for iOS is going to present me with some new challenges that I wouldn’t normally have to contend with such as Memory Management, which is going to take some getting used to, but that’s half the fun. So hopefully before too long I’ll be posting about my new app that you can all go and buy and make me millions, (although based on how many readers I probably have I might be lucky to make a pound!). I promise it won’t be a new fart app!
]]>t all started with the arrival on the scene of microjs.com by Thomas Fuchs and Dustin Diaz. For those of you who haven’t heard of it, microjs.com is an index of micro frameworks curated by Thomas and Dustin. The requirements for inclusion on the site are as follows:
I liked the idea of this and was keen to get a listing on there as a step towards my goal of becoming more known in the community. Unfortunately none of my previous projects met the requirements, so if I wanted in I needed to come up with something else. I’d seen a tutorial in .Net magazine on image editing using javascript and canvas and decided I could port my existing PHP ImageHandler class to javascript using canvas as a base.
I also decided to use this as an oppurtunity to try out CoffeeScript which I’ve been hearing a lot about. Once again, for those out of the loop, CoffeeScript is a lot like Sass, which I’ve mentioned previously, but for Javascript. It’s a language that compiles to javascript, so you can write your code in CoffeeScript’s clearer, more verbose syntax, then compile it to normal working syntax.
I’m not normally a fan of stuff like this as I’ve never really seen the point, if you want to write javascript just learn javascript. However both Sass and CoffeeScript have convinced me that there are benefits to these things. In the case of CoffeeScript the automatic handling of things like scope and variable declaration make developing a lot easier and safer. The automatic wrapping in a function did cause me some confusion at first, which I’ll discuss later, but does prevent any unnecessary pollution of the global scope and can be turned off with a compile option. I am however still adjusting to the braceless syntax which I’m not too keen on. I appreciate that it makes the code cleaner and smaller but as a php developer predominantly I’ve grown used to curly braces or at the very least some kind of ruby-esque closing statement.
I decided to stick with a small selection of basic image manipulation functions to start with. As I was using my existing PHP library as a starting point I had a ready supplied list of functions to use, with the basic logic all worked out. All I needed to do was work out how to write the functions in CoffeeScript and understand how to apply them with canvas. The latter proved to be the more challenging task for the most part. Particularly due to the inconsistencies in how the W3C’s canvas spec is implemented in Gecko and Webkit. The main issue I came across was when working on the rotate function. I had been using the globalCompositeMethod copy to overwrite the existing canvas data which worked fine in Firefox but in Safari and Chrome “copy” actually overlays the new data onto the old, so the original, unrotated image was still visible. I ended up having to create an internal canvas object as a kind of staging area so all manipulations were performed on that before the finished article was sent to the target canvas.
By far my favourite CoffeeScript feature when writing this was the way it handles scope and the ability to reference the parent object easily when writing the code made life considerably easier, particularly as all the functions perform operations on internal objects. For any of you who haven’t played with CoffeeScript yet or aren’t familiar with the scope handling, it works like this:
Which will compile to this
Notice that CoffeeScript adds the __bind function which is then used to make sure the function executes in the object scope. Granted you can write this yourself but the syntax of the CoffeeScript is a lot simpler and clearer as to what is going on.
After a few weeks of playing around I got Obscura into a state I was happy with for a first version release. It passed all the tests for inclusion on microjs.com, coming in at 1.5K compressed and gzipped, so I submitted it for inclusion and got it accepted. Obviously I was pretty pleased about this as it was one of the main reasons for writing the library in the first place and it was great that my work was considered good enough to be accepted onto the site but it didn’t stop there. Later in the same week I got an email from Softpedia informing me that one of my projects had been added to their Scripts section. At first I had no idea what they were talking about as I hadn’t submitted anything to Softpedia.Upon further investigation it would appear that they’ve been scanning other websites and finding libraries and widgets to add to their new Scripts download section. The project they’d added was Obscura so what I’m guessing has happened is they’ve been scanning through microjs.com and adding projects from there. It also appears they’ve been using those projects as starting points to find other projects as throughout the day I got more emails telling me they’d added other projects that are on my blog and github account. By the end of it 7 of my projects had been added; Obscura, Uncharted, Zebedee, ermintrude, Easel, tipBox and Delorean. For me this was a huge breakthrough in terms of what I’ve been trying to achieve this year as it’s providing more avenues for people to find out about my work and hopefully use it and help improve it. It’s also resulted in people starting to watch my GitHub repositories so hopefully I can build on this and keep raising my profile as the year goes on.
For now feel free to check out Obscura on GitHub for the code and demos
]]>First up was finding out how to do encapsulation in javascript so that I was only giving access to the methods that needed to be accessible from outside the class. The way this is done is to return an object with the public methods defined in it, rather than doing return this. For purposes of scope I defined the methods before the return statement, then returned references to them. Like so:
Once I had that that figured out it was down to creating the various methods and setting up the event listeners. The main requirement was handling the positioning of the tool tip in relation to it’s trigger element. As the position could either be fixed to a point on the trigger or follow the mouse, I ended up creating an object with either the element properties or the mouse coordinates and using that as the starting reference to perform the calculations from, then scanned the position option for one of the y position possibilities and set the top and did the same for the x position options. I later expanded this to have an optional element passed through which would be positioned instead of the tooltip, for use with the animations.
I spent a lot of time going through prototype and zepto to find out how to do the various things I needed to do without the frameworks and ended up stealing various little bits of code, like the user agent regular expressions from zepto so I could determine whether the browser was running webkit, I also tweaked this to check for gecko 2 as well. This was so I could use css animations where available for the transitions. When it came to dealing with the animation, emile.js ended up being my main source of reference, to the point that when I needed to expand my original animation function to be more flexible I ended up taking emile’s animation code and a few of it’s helpers and tweaking them for my own purposes.
The biggest challenge with doing the animation was the scale transition and positioning it, particularly the css animations. With the javascript animation it was easy to make the box appear to grow and shrink from it’s trigger element, as I just needed to call the position method each time I adjusted the size. But with the css couldn’t call anything on each iteration so I had to create a test element that was a clone of the tool tip, alter that, reposition it and get the end values, to then pass through to the animation function. In the end it worked out but I’d like to play around with it to see if I can get something less long winded. I also want to have a play to see if it’s possible to make the text grow and shrink with the box, by using ems. Another interesting thing I discovered while working on the CSS transitions is that both Gecko 2 and Webkit have their own version of the transition end event, in Gecko 2 you can use transitionend but in webkit you need to call webkitTransitionEnd. Also this event will get called for each property you are animation, so in the case of the scale transition,where I was animating width, height,left and top, the event was being called four times. Remember to check for this when writing your handlers.
I ended up namespacing the tool tip function inside a tipBox object, so I could add the scan method and keep them together. This means that while the calls are a bit longer, the functions are kept neat and secure, and shouldn’t conflict with anything.
The scan method enables you to have a load of elements on a page (preferably a tags for semantic reasons) with a given class name that you can turn into tipBox triggers with one function call. All you need to do is pass the class name and the options you want to use to the method and it will scan the page and set up the tipBox for each one, using the title attribute to supply the text.
I found getting the initial stages of the widget working were a lot easier than I expected, which I take to be a good sign that my understanding and knowledge are improving (either that or it’s easier than I thought and I’m just being a numpty). The animations presented my biggest challenge and took as much time to work round as everything else did to create but were without a doubt the most rewarding part of it to complete. The whole coding without a net approach forced me to explore and learn more, and work out my own solutions to how to do things, which was great fun, and will hopefully result in an improvement in my javascript work from now on.
Code and demos are available on GitHub:
]]>For the large part I’ve kept the code the same on the new versions, the main changes being updating the open and close methods to use each individual library. I’ve also removed functions that were duplications of methods available now available to me in Prototype for the Scriptaculous and Scripty 2 versions. I did however keep my own object merge function as it merges more recursively than Prototypes version. Emile however was much more of a challenge as it is solely an animation framework and therefore contains no helper methods whatsoever. Cue a trip deep into zepto’s code and the Mozilla Javascript Docs to find out how the frameworks do things. I ended up adding a few helper methods to deal with manipulating the classnames, just to make life easier.
I’ve also added in the facility for the Scripty 2 version to use Scripty 2’s ability to use css transitions where available. This is only available on linear and sinusoidal transitions at the moment but the library will fallback to javascript for the unavailable transitions. In the case of emile the transition calculation functions have to be provided as an option so I’ve added a zebedeeTransition object with a selection of functions. The default object just includes the linear and sinusoidal transitions but by including the zeb-transitions.js file you can get access to all the transition types of Scripty 2. The calculations are taken from Scripty 2’s included calculations that are based on Robert Penner’s original AS2 easing equations.
Coming up in version 0.3 will be a jQuery version, callbacks for when the panel opens and closes, at both the start and finish of the animation, and the option to keep one panel open at all times.
]]>While I know python is a popular, and very capable, web programming language, I’m not really interested in that side of it. As far as I’m concerned I’ve got PHP which I use for regular development, and am pretty competent with, and Ruby on Rails, which I’m starting to try and get my head round, I neither need nor want yet another contender vying for position as my chosen tool when it comes to developing for the web. What I am very interested in python for, is desktop apps. From what I’ve heard python is a pretty good cross platform language with good tie-ins to the operating system and file structure. It also looks a hell of a lot simpler than C++, which I have tried to master on a few occasions and only ever succeeded in achieving basic competency with.
Now if you’ve seen any of my other posts you’ll know that I tend to do a lot of work with Javascript, and also know Actionscript, so you may be wondering why I don’t just use Air for building desktop apps. I’ve used Air before to build small desktop widgets using Actionscript, and will undoubtedly at some point end up playing around with it a bit more, but for users to run Air apps they’re required to download the Air runtime, and the last time I looked the Linux version was a bit behind. What I’m hoping to get with Python is something I can write once, maybe with some os specific tweaks, and compile to a valid executable/installer for any system.
So onto my first impressions. For someone that is used to languages like PHP, Javascript and Actionscript, Python is something of a shock to the system. The lack of curly braces to enclose functions and statements was something I was starting to come to terms with from Ruby, but the lack of any form of closing statement made reading through the code a somewhat strange experience. My learning project is a file renaming utility so I found the os functions, particularly os.rename() really useful. I started off just building the app as a command line script, then once I’d got that basic renaming functionality figured out, (not really that difficult when it’s just a call to one built in function), I started looking into adding a gui.
I ended up going with PyQT4, mainly because it was the only free, cross browser GUI framework that worked with Python 3. The hardest part about getting it all working was finding out how to actually create the window and use the ui. I’m using the following code:
Where main.ui is my layout xml file. One of the things I liked about PyQT was that it came with a GUI designer utility which lets me just layout the gui as I wanted it and save it to xml. Makes building the layout much easier. At the moment I’ve not really done much more than set up a basic gui with ultra simple file renaming (you select a file, type a new name and hit the big rename button) but I’m intending to add batch renaming with various renaming actions such as regular expressions, substringing, extension changing and more.
The main challenge at the moment is understanding how to use PyQt as I’m afraid the documentation isn’t particularly novice friendly, being more of a reference library. Some examples would be handy, especially as I struggled to find anything on google. I think when I’m a bit more comfortable with things I’ll post some examples/tutorials. I’ll also write a bit more about my python experiences as I get to spend more time with it.
]]>It was good fun having to go back to basics on it as I was used to having Prototype and Class.Create() to work with when creating new objects. Thankfully zepto provided a few good utility functions to keep my code neat and simple. The jQuery like chaining also came in handy in that regard.
I’ve purposefully kept the functionality simple, as I don’t really think it needs to be all singing, all dancing! At the moment it supports vertical and horizontal accordions and I will probably be adding the ability to set the the actual trigger event for the accordion to be bound to a child of the header object. Also the duration, transition type and trigger event are all configurable, as well as the class names assigned to the various components.
I should hopefully be adding support for Scriptaculous in the next month or so, and Scripty 2 should follow soon after that, so watch this space. In the meantime checkout the project page at the link below for more information and links to the GitHub source. I’ll also be popping up some demo pages when I get the chance.
]]>So first up, purely by virtue of being my most recent, is Easel, a colour (I’m english, so yes it is spelt right!) manipulation library for Actionscript 3. Easel came about from a need to take a randomly generated colour and get colours that would work well with it for dynamically generated objects in a recent project at work. At first I just managed to find the Tint library by RevokeLabs which provided me with a darken function which did the trick for me. However I then needed more, so I managed to find an algorithm to calculate the complementary colour on a forum somewhere, which I’m afraid I can’t remember, but have subsequently replaced so I don’t feel too bad about not crediting it. From there I had the idea of replicating the colour manipulation functions of Sass, which I’d read about in a recent .Net tutorial, but hadn’t had a chance to play around with (I have now and will no doubt be writing more about this down the line, watch this space!).
I was struggling to find the algorithms to accomplish what I needed in AS3 so I ended up pulling the source for Sass from GitHub and wading through that to find what I needed. I then proceeded to rewrite the functions to AS3 which involved rewriting the original manipulation functions from the Tint library as they relied on manipulating the RGB values whereas Sass was working with the HSL. I did however keep the getHex and getRGB functions as there seemed to be no real difference in them. The upside to this approach was that I learnt a bit about colour manipulations, and got more experience with Ruby code, always a good thing!
Please check out the link below or on the right for the project page which contains links to the GitHub source and the Demo.
]]>In actual fact this goal was something I set myself towards the end of last year, which is when I first started setting up this blog, but I never seemed to find time to actually kick it off. I guess that’s what New Year’s resolutions are all about, making you take that step. So here goes, the blog is now officially live, and you are now, hopefully, reading the inaugural post.
I’m going to try and post as often as possible on here, probably monthly at the moment until I find enough to write about more often. I’ll also be gradually adding pages and links for my various open source playground projects, so I’ll undoubtedly be posting to launch them and keep you all updated on their progress.
Here’s to 2011
Will
]]>