In a recent conversation, I was asked if I knew what XHTML was. Much to my dismay, I did not. I mean, I could make some guesses (and did): the HTML part was pretty clear, and scrabbling together context clues I correctly inferred that the ‘X’ stood for extensible. But as to what XHTML was and how it differed from HTML or XML, I didn’t know.
So, on that note, today we’re going to learn about XHTML.
Read on →
NOTE: As I’ve found too many interesting methods, this will be a two parter, with five more methods to come.
One of the biggest challenges of learning Ember (or any framework really) is familiarising yourself with all the tools it provides. Sometimes I’ve needed a tool and not known that there’s a specific function baked in that does what I need. Of course there are great resources out there like Stack Overflow and the excellent Ember community Slack channel, but even then sometimes it’s tricky to find what you’re looking for.
Read on →
This blog is a simple one - I just wanted to write a bit about a neat technique in ES2015 for declaring and assigning variables that I was heretofore unfamiliar with: destructuring assignment.
Recently, while reading a blog post on implementing drag and drop functionality in Ember.js with HTML5, I noticed a method of variable declaration in JavaScript that was new to me. In the code for a specific component, I saw this:
Read on →
A little earlier this year, I was reading an organisation’s style guide for working with Ember.js, when I encountered reference to the use of ‘query params’ in a controller. At the time, still relatively new to Ember, I had no idea what this meant. In the intervening time, though I’ve learned a lot. Basically, query params allow for certain application states to be serialised into the URL that wouldn’t be otherwise possible through the regular use of routes. In this blog post, I’m going to explain the role of query params, and how they can be used in your Ember app to provide some neat functionality. I’ll be using a sample Ember.js front-end app, with a Rails API on the back-end.
Read on →
The Rails Asset Pipeline is a really great tool that improves performance by compressing and minifying assets, as well as compiling JS and CSS assets written in other languages, like CoffeeScript and SASS. When compiled, the files in your app/assets/javascripts/ folder get processed and minified into a single application.js file. In many cases, this is great - all of the views in your app have access to this file at all times, and it cuts down on the number of server requests made by the browser. But what happens if you want to dynamicaly scope JavaScript functions to specific pages in your app, like a function that only fires when an object view page is loaded?
This week, as part of the Flatiron Students Present series I gave a presentation on the new features coming in Rails 5.. There’s some really intriguing stuff, highlighted by the Railsified websocket goodness of Action Cable. Nestled in there is the news of Turbolinks 3 Turbolinks 5, the latest version of a Rails feature I was totally unfamiliar with.
layout: post title: “Bootstrap: Making front-end development easier since 1842 (note to self: check dates)” date: 2016-01-12 07:41:35 -0500 comments: true
Throughout the first six weeks I’ve spent in the Flatiron School’s Web Development immersive course, we’ve largely stuck to the dark and bewildering world of the back-end, wading waist deep into the nitty-gritty muck and grime of SQL databases and Model View Controller designs. There’s been a lot of plain code on plain screens.
But you know what? Sometimes it’s nice to feel pretty. So today I’m going to talk about front-end frameworks.
Read on →
EDIT: I literally wrote this post the day before I learned what SQL was. Oh the folly of youth.
Earlier in the week, when working on a little NBA player stats CLI program, I had my first run in with Ruby’s PSTORE class - a mechanism that allows you store Ruby objects that persist between instances of the program running.
Read on →