Each time I sit down to do a piece of front-end web development, I find myself revisiting the syntax of CSS and LESS, as well as double-checking on HTML elements, then trying to remember when I precede a selector with #, &, >, ::, Caps, etc… In short, I always spend a bit too long getting things straight in my head (again) – although, arguably, it may well be as much procrastination as anything else!
This post is my personal documentation for next time…
With the coming of spring, I feel the need to inject a touch of colour into my Application. I actually need to tackle the overall look and feel to sort out my preferred application interaction patterns, but some of the ‘feel’ components are looking particularly challenging. So I’m starting with the ‘look’ as my semi-productive way to delay the inevitable brain drain until next week…
My challenge: How do I customise the default styles provided by Twitter Bootstrap, without creating a maintenance nightmare?
The short answer always sounds so easy: create my own stylesheet to hold all my overrides.
The longer answer needs more than a ‘monkey see monkey do’ approach (when something invariably goes wrong, this monkey gets confused) so I had to dig a little deeper to try and better understand how it all integrates. For example learning that @import is not the same as requires_tree. For example, learning that things behave differently in Dev vs Prod because of the clever way the asset pipeline and sprockets handle compiling in different modes. And a whole lot more. . .
Like all things in software, there’s ways and there’s better ways! So here’s my longer answer… Continue reading
It ain’t pretty – but it works!!! Finally, two months into my goal of creating a web-based app, I have made real progress: A complete, end-to-end interaction via my new application!
Phew! Just in time for the first Stage Gate assessment, originally scheduled for 2 months after my project start date.
My app only offers two options so far: register new user and user login. But that simple start entails a bucket load of infrastructure. Furthermore, that start has effectively leveraged the recommended TDD (Test Driven Design) approach which means that the app does what it is expected to do, as proven through the truth table tests that define and drive the whole security build and test. So yes to all you doubters – it is very well tested! Who’d have thunk a test manager cared about that stuff!
Stage Gate 1 – Do I have to go back to my old job – or is there hope for this new trick?
Now, no more shenanigans, no more tomfoolery, no more ballyhoo…
This week I have started real work, on a real app!
All the sample apps and sample testing of said apps means that I am now more likely to be able to look at a piece of code, or a test, and have some clue about what it is doing. Create code of my own even… so some clue is actually pretty good.
The amazing thing about using twitter bootstrap, plus Devise, plus templates, is that Ruby on Rails actually generates most of the code on my behalf, leaving me to worry about my unique stuff. So, in creating my first entity yesterday (a ref data table), all the generic user security framework was there. As was the basic look and feel, and the new data table, and all the database services to manage each transaction type. All I had to do was decide what I will allow each user type to do, and what will be locked down or removed all together.
By lunch on the first day, voila! Coding and testing of my first ref data table was complete. One step forward!
My sourdough starter, affectionately referred to as ‘the bug’, has just turned 4. It’s done pretty well for a 4 year old. From its home in Oz, it has taken regular summer holidays in NZ (amazes me what quarantine do and don’t worry about), some wonderful beach weekends in Mollymook, and holidays being bug-sat with friends. It’s spawned offspring in NZ, Oz, Japan, and Malaysia (although I’m not sure how many of those survived beyond the initial excitement of the idea of fresh bread).
For the past four years, we’d settled on the pattern of hibernation (i.e. feed it and park it in the fridge) during the week, with spurts of activity on the weekend.
While it took Linus Torvalds just 2 weeks to initially create Git and start using it to manage the Linux Kernel source code, this mere mortal is still struggling to fully grasp the simplicity of Git after dabbling for 3 weeks.
To-date, I’ve been using a handful of the git commands, but without really understanding how Git works: as such, the consequences of some commands were a bit of a mystery. I didn’t appreciate how Git handles and tracks changes, nor where everything lived. After 3 weeks and two branching debacles, of my own doing, it’s time to stop hacking around the fringes and get over this learning curve… Maybe debacle is an exaggeration, realistically I couldn’t follow what was going on when I was cloning, branching, committing, staging or simply working.
At the start of week 3 it became clear that I really did need to get on the horse, and become a code monkey (yes, too many animals in that sentence so let’s hope my app design is better than my prose!).
Building my first web app should be a pretty simple task given it’s just a handful of low complexity views, simple user interactions, and simple data relationships, especially since the lessons I’m following provide very explicit instructions and sample code snippets. Simple! Or so you’d think…