Ever tried to rename a file to use a dot at the beginning on Mac OS X? Had it fail?
The workaround is pretty simple, albeit annoying. You’ll have to do the operation through the terminal:
mv myfile .myfile
For a bonus tip, to show hidden files in the Finder, simple press cmd+shift+.
Doing it again will hide them.
Quick tip! If you encounter an error similar to:
'.../some-module.pcm' is out of date and needs to be rebuilt: signature mismatch
in xcode while building your React-Native application, then the quickest solution is to delete the build folder and re-run the build from scratch with
react-native run ios
It takes a lot to slow my mind down, to just be me. I can be acerbic, callous and I often worry about a vein of arrogance in my personality that I can’t seem to shake. I have a big mouth too, which doesn’t help matters. I’m also fortunate and privileged beyond belief, and I’d like to take some time to calmly recognize the people and circumstances that became the shoulders I stand on.
All of my success is owed to the people who gave me a chance, sometimes many of them. My father, Bill Sedgwick, is the first and last of them, encouraging and reprimanding me in all of my choices. His shoulders are the broadest, his perspective the clearest. Michael Ginn, a longtime friend and mentor in both life and the martial arts will take the second place. Family will always be patient, but friends have an out. Ten years and counting he never took it.
The next on my list, David Humphrey, is also the most recent. A widely respected software engineer and professor, he allowed me two chances to involve myself with Mozilla, a place where I met the likes of Pomax (Mike Kamermans), Jon Buckley, Kate Hudson and countless others. In the course of my work under Dave I tried absorbing more than just technical knowledge. His character and work ethic, which earned him an award from the Governor General of Canada, were just as humbling.
My colleagues at Seneca College’s Centre for the Development of Open Technology stayed patient with me, which I can’t imagine was easy. I think specifically of Chris DeCairos, Ali Al Dallal, Gideon Thomas and many more. My enjoyment of being outclassed largely started with them.
I have a career I love now, and it is thanks to all of you. The most precious resource is opportunity, and I’m devoting my life to paying those opportunities forward ❤
So, in other news, nothing huge or anything, but I graduated from college (!)
So, in other other news, I’m thrilled to say that I was also able to find a job pretty much immediately (!!!).
I’m extremely thankful, and I’ll be posting a little bit more about the weight of these two facts, along with the people behind them, another day. Instead, I’d like to recount my experience of diving into a proprietary codebase (you don’t mind signing an NDA do you?) and trying to figure out the best way to learn it.
My work with the Centre for the Development of Open Technology had me delving into different open-source libraries, sometimes deeply, sometimes not, but always as a new contributor. The focus then was figuring out just enough to be able to fix something urgent, or to implement some new feature. It might be that I should be taking a similar approach with my new work, but this remains to be seen.
The only time I ever intimately knew a codebase was when I either helped build it from scratch or gutted it entirely, effectively rebuilding it from scratch. This time I’m in a position where I need to be an expert across the domains our team is responsible for, and this warrants a rethink of my approach.
On the one hand, not much has changed. There’s still work to be done at the expense of technical debt, deep learning and refactors. On the other hand, I was hired to relieve my full-stack co-worker of the back-end side of things. I won’t be much of a relief if he has to clean up my messes when I didn’t understand the implications of the changes I was making!
It boils down to research versus product development. I’m not solving problems in uncharted lands anymore. Now it’s very much that “we know it’s possible, so get on and do it”. Since this is a salaried position, I think it’s reasonable to expect me to learn the codebase, even if I have to put in some extra time outside standard business hours. If anything, it’s an expansion of the investment required and I’m okay with that.
My first big task is to implement a metrics collection system, similar to New Relic, for our product. This is to be an internal tool we can use as a basis for optimization. In the words of our product lead, Johnny: “To optimize, first we must quantify.”
The design process starts today. Updates to follow!
This was a short week, but full of things to do. With Monday being a holiday and another day devoted to middle-school workshops I had a lot on my plate! The main task was to finish adapting the Filer library for use in Node.js.
Saying, “I’m making Filer work in Node.js!” is slightly misleading, since the true goal was to add Node.js support to the list of compatible environments.
Filer had been built to work in a browser environment, and could be included in two different ways.
First, as a script include in an HTML page, where the Filer instance becomes attached to the global window object:
<head> <script src="../Filer.js"></script> <script src="main.js"></script> </head>
// Main.js // Do something with filer window.Filer(...); // Or, because of the global scope, Filer(...);
And second, loading Filer as part of a RequireJS module system:
<head> <script src="../require.js" data-main="../config.js"></script> </head>
// Config.js
require(['filer'], function(Filer) {
// Do something with Filer
Filer(...);
}
David Humphrey took care of the first challenge towards cross-compatibility by removing or replacing references to environment specific variables, such as the window object mentioned above.
The challenge was the module loading system being used to solve the problem of dependency injection in the Filer codebase. In simple terms, the code was split into multiple files, any of which might need to access any of the others at pretty much any time. The original solution was the AMD-styled RequireJS module system, which allowed each file to pull in the other files they needed. With the use of a special library, this system of interconnected files could be combined into a single distributable file for user consumption.
I spent a good two and a half days writing a patch to get that part of the process (the combination of the files) to result in something that worked in Node.js, and I succeeded!
The largest challenge was having a single codebase that would selectively choose which external libraries to use depending on the environment Filer was running in. Long story short, I had to hack my way to victory… and it was messy.
What a mess!
Like the week before, I taught 4 workshops with Yoav on the topic of web development as a career. Things went far smoother this time, since we had some experience under our belts.
More to follow!
Our first week of our first sprint was a good one. I spent the majority of my time at the office automating the build/release process of the virtual file-system we’re currently patching. Then, I was called on to visit a middle-school to talk about web design, web development and what it’s like as a career. I’ll touch on both of these topics.
Build things while I’m sleeping!
I’ve never had to work with complex build systems before. My minimal exposure to them was in the form of C++ makefiles, and it really was minimal. Enter GruntJS, the JavaScript task runner built on NodeJS!
Grunt takes units of work, called Tasks, and executes them in a pre-configured order. Each of these pre-configured orders is also a task, so this type of setup in a project’s Gruntfile.js config file is common:
grunt.registerTask('task1', ['3rdPartyTask1', '3rdPartyTask2']);
grunt.registerTask('task2', ['task1', '3rdPartyTask3']);
Writing custom tasks for reuse isn’t difficult, having a similar pattern to a typical node module:
var dep = require('someNodeDependency');
module.exports = function( grunt ) {
grunt.registerTask(
'customTask',
'This task does a custom thingy.',
function(runTimeOption) {
do.stuff.with.dep();
});
};
This task can then be loaded as a 3rd party task, of which there are many. My goal was to automate the build system, so I had to find (and in some cases, patch) a number of grunt modules. I found grunt-npm for NPM publishing, grunt-git for git manipulation, grunt-prompt for pretty command line prompts and grunt-bump to help create new version releases.
Combined, this is what my new custom task does:
If the user aborts…
For a patch version bump…
For a major version bump…
Aside from being extremely useful, this kind of automation was a lot of fun to implement. It’s also going to make releasing new versions of Filer much easier, improving on the release process considerably.
Another use of my time was visiting a local middle school for Career Day, where my colleague and I were tasked with running four workshops detailing the life of a web developer. Before the day, Yoav and I put our heads together to consider the format of our workshop. We took strong cues from Ali Al Dellal’s experience doing the same thing a few weeks before, and went with a hands-on workshop. We tasked the kids to follow the instructions in this Thimble make:
In short, they had to Open a new Thimble make, Find a cute picture, Insert the picture into the make and change the background/text colour. This took up most of the session, and was fun for everyone. We had to be very careful to explain things slowly, and in pieces. The students had trouble with each and every step. It was extremely gratifying when students would come up after the workshop and say things like, “I love computers! That was really fun.”
Four sessions and a free lunch later we were out of there, though we were scheduled for a second day the next week.
This was a tough week, with plenty of work and too little time. It was also very rewarding!
More to come.
I’m back at CDOT for the summer! A massive thanks to David Humphrey, Dawn Mercer and the Mozilla Webmaker team for giving me another opportunity to contribute in such a focused manner.
I’m going to keep this post as brief as I can. My re-introduction to web development came in the form of a challenge. I was to:
Right.
This was a good exercise, because it forced me to become reacquainted with how Nodejs logically organizes code that uses it as a framework. Using the CommonJS module system meant putting my parsing logic in a file with this structure:
module.exports = {
// Logic here
};
It also meant using the package.json syntax necessary for publishing an NPM module. This was nice review.
Once my parsing logic was complete, I had to figure out a way to make the same file compatible with the RequireJS and CommonJS module systems simultaneously. This was accomplished by encapsulating the module.exports code from earlier into a method named define() so as to keep RequireJS happy:
if (typeof define !== 'function') {
var define = require('amdefine')(module);
}
define(function( require ) {
return {
// Logic here
};
});
This was a fairly simple task, involving reading data from a file (specified as a command line argument) into utf8 format:
fs.readfile( path, { encoding: "utf8" }, function( err, data ) {
// Call my parser and print output here
});
This can be viewed at http://sedge.github.io/mdlinkparser/. The challenge was approaching this as if it were a completely isolated web application, that just happened to need to use a Markdown link parser. From this perspective, I would need:
Bower is powerful. As a package manager, it shares many similarities with Nodejs’ package manager NPM. For instance, bower has a bower.json configuration file that operates in a similar way to NPM’s package.json. Mine ended up looking like this:
{
"name": "mdlinkparser",
"dependencies": {
"sedge_mdlinkparser": "1.0.2",
"jquery": "2.1.1"
}
}
I leveraged bower further by adding an automatic build step by specifying a postinstall script that called grunt. I’ll get to this in a moment.
RequireJS is awesome because it ensures that the modules you need are fully loaded, with all of their dependencies included, before running your program logic. It has a simple structure for specifying which modules to load:
require( [ "dependencyName" ], function( dependencyName ) {
// Logic using `dependencyName` goes here
});
});
However! The javascript files that are used on a public facing website can have complex folder hierarchies, meaning that some work has to be done before a dependency can just be specified by name like in my previous example. Manually, it involves running require.config() before any RequireJS logic in order to establish symbolic links to the actual resources:
require.config({
paths: {
dependencyName: "path/to/src/dependencyName.js"
}
});
Being on a grunt trip, I decided I would automate the process. I found a grunt plugin, called grunt-bower-requirejs, that just needed to be pointed to the file that would run require.config() and would automatically configure the paths for me. This meant that I now had a Nodejs-based build system using grunt for a front-end bower-based system using Requirejs.
Running was a simple as bower install, since bower would then call grunt because of the script I specified in the file called .bowerrc:
{
"directory": "js",
"scripts": {
"postinstall": "grunt build"
}
}
I didn’t get to dive into LESS scripting for front end styling, but I hope to soon. I also spent a lot of time making sure my fellow CDOT developers were managing to keep up, and everyone seemed to learn the essentials as a result.
I’ve been co-developing a number of plugins for Mozilla’s Popcorn Maker web application. The codebase for Popcorn Maker is new to me, so I anticipated having a learning curve. I never would have guessed that the steepest part of that curve would be developing a keyboard with HTML and CSS!
I have experience with web development, and specifically creating HTML/CSS based designs, but somehow it never took. I always found the thinking required extremely taxing, and the troubleshooting tedious and fiddly.
Nothing has changed.
To be fair, designing this from scratch is only one of my options. I’m looking into other, pre-built, solutions but this is the best way to meet the functional requirements.
This particular design needs to be scaleable, which means no fixed widths allowed. I have very little frame of reference for good (read: efficient) website development practices, so I wrote a base structure that seperated the keyboard into basic rows within a container:
<div class="keyboard"> <div class="keyboard_row"> </div> </div>
The styling is also fairly simple at this point – I’m still not sure how I’ll use the keyboard_row, but the container is styled thusly (ya heard):
.keyboard {
width: 70%;
margin-left: auto;
margin-right: auto;
}
So far so good, right? Now things get tricky. How to represent an individual key? The complexity starts when considering how to display the value of the key itself. Letters are easy, but ENTER, SPACEBAR and BACKSPACE take up a variable amount of horizontal room.
I love bootstrap. It manages to eliminate most of the pain I’m going through with a robust grid system that is purely CSS based (to my knowledge). Unfortunately, including external libraries isn’t the best choice with a web app like Popcorn Maker – it’s heavy on the client-side processing already, so the fewer files it needs to download to display properly the better.
This leaves me trying to figure out how to fit all the keys in 70% of a space. And not just fit! They also have to look professional, meaning that they conform to the basic principles of good print design.
And not just look professional! They also have to maintain that consistency at any resolution, scaling properly in every respect.
I’ve tried a few different things, but my brain is officially fried for the night.
I’ll post again with my solution, cuz it’s gonna be a doozy.
Sedge Stuff 