As part of tackling how to customise bootstrap, I ended up trawling through stacks of stuff. Rather than making the Colour my BootsrApp post really long, this post is my dumping ground for some of the more helpful links.
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
Implementing a datepicker – Simple ( not…!)
My RoR app is using twitter bootstrap for all my styles. Not only does this significantly reduce my need for extensive front end development, it also provides a responsive framework to enable the app to deploy to a range of devices.
The standard date field in the Twitter Bootstrap is a slightly clunky-looking set of fields for entering each component of the date (and additional fields for entering time):
I prefer a single field, and would also like to provide a date-picker option – it’s pretty standard to offer this and I prefer to see a future date in context of weeks and months. So I landed on the following, which displays the date picker when the field gets focus, but which also permits keyboard typing of the date:
So, with the goal set, it’s time to figure out how to actually implement this!
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.