Get your OSX Terminal groove on!
https://github.com/barryclark/bashstrap
[EDIT] Wow, nearly exactly five years later, I still use this on every new OSX machine…
To add powerline too, here’s a handy guide:
https://medium.freecodecamp.org/jazz-up-your-bash-terminal-a-step-by-step-guide-with-pictures-80267554cb22
Really? Who needs a border-radius generator? It’s SO SIMPLE!
Actually, it’s a little more complex than that – I saw a great talk a while ago (I really should have blogged it) where the presenter explained a little known feature of border-radius. She explained, with some style as I recall, how you can have different horizontal and vertical radii on a single corner.
Oh yeah – funky shapes ahoy!
Really, would you expect this to be a single HTML DOM element with standard CSS?
However, it’s not as intuitive as a standard one value radius, so this generator from MDN helps to play around with the values until you get the shape you want.
[UPDATE 2018-10-17] Here’s a more modern version, with a nice interface, though the Mozilla version does have the ability to drag two points at once.
Burn it! It’s a witch!
Nah, not really… PubSub is awesome.
But sometimes it might be a little more than you need. Many events are published (or ‘pubbed’) in conjunction with a dom state change being triggered. What if you could simply listen for the state changes without having to subscribe to a pubbed event?
|
1 2 |
// How about a more performant way to listen for custom tooltip nodes document wide? document.addSelectorListener(‘.tooltip:hover’, function(){ ... }); |
Sweet.
Oh dear lord – CSS browser hacks are horrible. There should always be a better way, right? Feature detection is king!
Sadly, not always. But applying a Modernizr-like approach to target specific criteria based on classes just for the required use case is a good approach, when possible. But for fine grained control of specific browsers and versions this just doesn’t really work.
Or, maybe it does? This nifty technique allows for incredibly fine grained control. It’s simple, lightweight and unobtrusive to the user.
As whizzy HTML5 animations and interactions spread across the net like virulent virii, maintaining high performance is key if you want to look good.
With this in mind, Paul Lewis, together with tips from Paul Irish, has put together a very helpful checklist. Once you understand the pitfalls, it should become easier to avoid costly operations and improve performance from the off…
Some useful utilities for native style HTML5 device development.
Man, there’s some good stuff out there today…
A fresh approach to JSON loading that speeds up web applications by providing the parsed objects before the response completes.
So far so cute…
Oboe makes it really easy to start using json from a response before the ajax request completes. Or even if it never completes.
(Emphasis mine)
Oh boy – that’s great!
As the use case example explains:
Sarah is sitting on a train using her mobile phone to check her email. The phone has almost finished downloading her inbox when her train goes under a tunnel. Luckily, her webmail developers used Oboe.js so instead of the request failing she can still read most of her emails. When the connection comes back again later the webapp is smart enough to just re-request the part that failed.
BOOYAH!
Cute!
http://theironcook.github.io/Kojak/
Requires a shim to work with obscured files though, á la RequireJS.
I was talking with a potential client yesterday about a web app that they wanted to make as ‘native’ as possible. One barrier to getting that fast loading native feel is the number of HTTP requests when loading new data. We discussed using a framework with minimal templates and local cache to reduce the amount of data being requested, but it would be great if the number of requests could be minimised too.
Shazzam: DYNOSRC!
Eliminate HTTP requests for JavaScript files and serve differential updates to your users on the fly.
Okay, I’ll bite: how?
Minimize HTTP Requests – DynoSRC loads JavaScript files inline in your HTML response, then stores them in localStorage. You can even inline the DynoSRC client lib, eliminating all HTTP requests for JavaScript on your site.
Wait? Whut? Inline JS? That sounds wrong! But by storing them in localStorage and eliminating the need to reload, and completely removing the HTTP requests… that sounds like one step back, two steps forward. I’m intrigued…
Differential Updates – Now, if a JS asset on your site changes, your users will have to download it again even though just a fraction of it changed. DynoSRC sends down differentials updates, so changes to large files don’t require full downloads.
Yeah baby. That’s where it’s clever.
Issues:
Requires NodeJS server
Could be greedy it seems, so probably better for smaller apps without a massive codebase at the moment, but can be configured to only work with certain assets.
Keep an eye on this one…