My little boy has recently become old enough to enjoy going to the movies. What could be better than taking your kids to the movies on a Saturday afternoon?
But I've found that many, if not most, supposedly G-rated movies almost always contain frankly absolutely terrifying scenes that are often quite extended. My boy jumps off his seat and hides and doesn't watch.
Many of these scenes are very, very scary. EVERY Pixar G-rated movie includes scenes that are terrifying to children.
But why? Why does Hollywood feel that every movie, even for tiny children, has to include deeply frightening scenes? I don't understand. It seems like the accepted wisdom is that "to frighten is to entertain".
It's almost like Hollywood feels that movies just won't sell unless it can scare children to the bottom of their little souls.
https://www.youtube.com/watch?v=hHs_KhePqEM
https://www.youtube.com/watch?v=3MIX33DO16c
Monday, May 25, 2015
Wednesday, May 20, 2015
For Linux, your core skill is navigating broken stuff, which is everything.
In the Linux world, as others before have said, "everything is broken".
If you are a developer or sysadmin doing anything of any significance then your ability to reach your goal is defined by how quickly and easily you can recognise and find workarounds for broken stuff.
Actually, not everything is broken, but so much is broken that it feel like everything. It's the broken stuff that will take your time. The stuff that isn't broken will be easy and will happen quickly.
So the faster you can jump through Linux's never ending minefield, hot coals, machine gun nests and shards of glass, the faster you can get productive work done.
Wanna be productive? Get good at seeing and sidestepping and fixing broken stuff.
If you are a developer or sysadmin doing anything of any significance then your ability to reach your goal is defined by how quickly and easily you can recognise and find workarounds for broken stuff.
Actually, not everything is broken, but so much is broken that it feel like everything. It's the broken stuff that will take your time. The stuff that isn't broken will be easy and will happen quickly.
So the faster you can jump through Linux's never ending minefield, hot coals, machine gun nests and shards of glass, the faster you can get productive work done.
Wanna be productive? Get good at seeing and sidestepping and fixing broken stuff.
Sunday, May 10, 2015
An incredibly brief introduction to JavaScript in 2015 for experienced developers.
Over the years I've done bits and pieces of web and JavaScript development. For one of my current projects however I need to get some serious stuff done, so I knew I had to come up to speed on the state of the art in browser development. I chose to target react.js as it seems to me to promise the simplest mental model which is what I need because I am time poor.
And things have changed ALOT in JavaScript development since the old days. It took lots of searching and reading to make sense of the current landscape so I will now save you days of effort and summarise what you need to know:
1: Programming a web browser directly with JavaScript is dead. In the same way that few people now programs CPUs directly with assembly language. When you are writing JavaScript it now gets compiled (actually transpiled) to JavaScript. Forget writing code directly for execution in a browser, those days are gone, move on.
2: There are a number of JavaScript variant languages for you to choose to program in. The mainstream choice is now ECMAScript2015, also known as ES6. ECMAScript2015 /ES6 turns JavaScript programming into something sane, for lots of reasons but primarily because it implements a module/import system.
3: Your development workflow involves writing ES6 code then shoving it through a series of very useful tools that carry out transformations of your code. The main transformation is the transpiling (converting your ES6 code to plain old JavaScript e.g tools like 'babel'). Other transformations include minifying (compressing/reducing the size of the output, e.g. 'uglify'), uglifying or mangling (making your code to make it harder for others to make sense of - 'uglify' does this too), bundling (combining multiple JavaScript files into a single file to reduce load times e.g. tools like browserify), translation (if you are using reactjs then you can write JSX which is like including XML style HTML in your JavaScript, this also needs to be translated as part of the transpile process). There's probably plenty of others but these are the main ones I have encountered.
4: Your development workflow will use some sort of tool to tie together all the transpiling and transformation tools. If you know what "make" is then you understand the concept. If not, well it's just a utility of some form that has a few different configurations of the tools mentioned above, each configuration useful for pushing your code through the various utilities until a final JavaScript file pops out of the end. "gulp" is the tool that people seem to be using alot at the moment for this purpose.
5: You will need to learn how to drive the Google Chrome debugger or spend a very long time in debugging hell. Go to YouTube, search for "JavaScript Debugging Chrome" and spend a few hours watching. Time well spent. The key thing you need to know is that JavaScript "source maps" will allow you to debug your code in the browser even after shoving it through the various transformation tools.
6: You will want to make use of various JavaScript libraries. This is done through the npm package management system. Invest some time in learning the basics of this. The key thing you need to know is that you say "npm install <packagename>" which installs packages under a "node_modules" directory in your current directory, which is where you compile from. In your code you will use "import" and "require" to load in the packages.
Hopefully that lightning introductions has helped you find your feet.
I'm learning all this. Have I got it wrong, please let me know.
And things have changed ALOT in JavaScript development since the old days. It took lots of searching and reading to make sense of the current landscape so I will now save you days of effort and summarise what you need to know:
1: Programming a web browser directly with JavaScript is dead. In the same way that few people now programs CPUs directly with assembly language. When you are writing JavaScript it now gets compiled (actually transpiled) to JavaScript. Forget writing code directly for execution in a browser, those days are gone, move on.
2: There are a number of JavaScript variant languages for you to choose to program in. The mainstream choice is now ECMAScript2015, also known as ES6. ECMAScript2015 /ES6 turns JavaScript programming into something sane, for lots of reasons but primarily because it implements a module/import system.
3: Your development workflow involves writing ES6 code then shoving it through a series of very useful tools that carry out transformations of your code. The main transformation is the transpiling (converting your ES6 code to plain old JavaScript e.g tools like 'babel'). Other transformations include minifying (compressing/reducing the size of the output, e.g. 'uglify'), uglifying or mangling (making your code to make it harder for others to make sense of - 'uglify' does this too), bundling (combining multiple JavaScript files into a single file to reduce load times e.g. tools like browserify), translation (if you are using reactjs then you can write JSX which is like including XML style HTML in your JavaScript, this also needs to be translated as part of the transpile process). There's probably plenty of others but these are the main ones I have encountered.
4: Your development workflow will use some sort of tool to tie together all the transpiling and transformation tools. If you know what "make" is then you understand the concept. If not, well it's just a utility of some form that has a few different configurations of the tools mentioned above, each configuration useful for pushing your code through the various utilities until a final JavaScript file pops out of the end. "gulp" is the tool that people seem to be using alot at the moment for this purpose.
5: You will need to learn how to drive the Google Chrome debugger or spend a very long time in debugging hell. Go to YouTube, search for "JavaScript Debugging Chrome" and spend a few hours watching. Time well spent. The key thing you need to know is that JavaScript "source maps" will allow you to debug your code in the browser even after shoving it through the various transformation tools.
6: You will want to make use of various JavaScript libraries. This is done through the npm package management system. Invest some time in learning the basics of this. The key thing you need to know is that you say "npm install <packagename>" which installs packages under a "node_modules" directory in your current directory, which is where you compile from. In your code you will use "import" and "require" to load in the packages.
Hopefully that lightning introductions has helped you find your feet.
I'm learning all this. Have I got it wrong, please let me know.
Subscribe to:
Posts (Atom)