I want to build a simple, static website using Bootstrap 3.2, including LESS. I also want to have a small number of pages rather than a single long running page. How hard can this be?
The answers to both questions were harder to find than I expected. There is a ridiculous (repetitive) amount of basic information on the use of Bootstrap Components & CSS and, to a lesser degree, the use and value of LESS. But I found sweet fa on how to get up and running in a useful dev setup. This post outlines my approach so it won’t be such a hurdle next time.
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…
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!