Creaming is one of those weird terms you see in baking recipes. It does have a specific meaning though, and doing it correctly can really improve your baked goods.
Creaming means mixing the butter (or the main fat of the recipe) and sugar (white or brown) until "light and fluffy". This process puts a bunch of tiny bubbles into the proto-cookies, which help with leavening. You should see the volume of the mixture increase by about a third, and has lightened in color, due to all that air. You shouldn't be able to see any sugar granules, but you should be able to feel them if you rub the creamed mixture between thumb and forefinger. Creaming will take somewhere around 3 minutes with a mixer (I like to use a paddle with a scraper or edge beater in my stand mixer), and just about forever if you're mixing by hand.
Not to be a downer, but that "free" trip you got by having your conference talk accepted is pretty far from free. TANSTAAFL, and all that. Here some additional "costs" you may have to consider. (Organizers: think about the huge commitment your speakers are making when they agree to speak. Try to make things as easy for them as possible.)
- Time off. Some companies are happy to consider conference-attending as work days. But if your company isn't, or if you're self-employed or a student, or have already done a lot of speaking this year and your company can't really cover any more, then you'll be using your PTO or otherwise covering these days yourself.
- Travel costs. Even if the conf offers reimbursement for travel costs, most do so within a few days of the actual conference. If that's the case, you're going to have to float the money until the paperwork and funding goes through. And unfortunately it's not uncommon to have to "remind" the organizers to process the reimbursements. This can be reduced by having the conf book (and pay up front) for as much as possible, but not all confs offer this and this isn't an option if you're traveling with a SO and want to sit together on the plane.
- Travel hassles. Travel can suck, particularly if you're going via airplane. Your odds of encountering that suck increase with every layover and international border.
- Eating. If you're traveling, you'll probably be eating out. There is almost never a per-diem covered by community conferences, so be sure you've budgeted for your food. Also consider any tourism costs if you'll be combining the conf with a few actual vacation days.
- Talk preparation time. How much do you value your time? Somewhere between minimum wage and your hourly rate? If you have a talk accepted, your new hobby is preparing that talk. Writing and researching and coding demos and practicing in front of people. Some magicians can write a 25 minute talk in 3 days. I sure can't. My talk preparation is like water in a pothole - it expands to fill all available time and space.
- Partner time. If have a partner traveling with you, odds are they won't attend the conference with you. But you'll probably plan to spend time with them; perhaps dinner each day and a few days touring after the conference. Be sure to work this all out ahead of time so that all expectations are met.
Want to take a spin in the good old git time machine? Here are some useful way to do that.
git show --name-only [sha]
- Show which files have changed between the referenced [sha] and the current HEAD.
git log --grep=[stuff]
- Show any commits where the commit message matches the regular expression [stuff].
git log -p [filename]
- Show the log (commits and changes) for a the file [filename]. You can add any
log arguments to this, such as 25 for only the most recent entries in the log:
git log -p -25 README.md.
git grep [stuff]
- Use the power of git to search for any matches of the regular expression [stuff] in the repo.
- If the results are too difficult to read in your terminal, you can pipe the results to your test editor. For example, to pipe the output to Sublime from OSX's Terminal:
git log -p -2 README.md | subl.
- Or you can pipe those results to a file to save them. For example, to send the results to a file in Windows' Command Line:
git log -p -25 > file.txt
Have you been thinking about contributing to open source projects, but didn't know where to start? Here are a few ways to get started. find projects which are actively welcoming new contributors by highlighting their "starter" issues - bugs which are small in scope or otherwise make a good introduction to the project.
Way back in 2013, I decided that it would be good for my professional development for me to attend some conferences. I had just started a new job, with some savings left over from unemployment time, and so I even had some budget to attend conferences on my own dime. I had met Carter Rabasa (founder and long-time organizer of CascadiaJS) by attending the SeattleJS meetup in the previous year. So I arranged a trip to Vancouver, BC for CascadiaJS in November. On the Hacker Train up from Seattle to Vancouver, I met Tracy Hinds, who had organized the Hacker Train all the way up from Portland.
CascadiaJS 2013 was an absolute blast. The talks were interesting and educational, and I met a bunch of new (and now long-time) conf-friends and even got mistaken for a speaker! I followed new friends on Twitter, and CascadiaJS on Github. Not too long after coming home, I wrote up and posted some of my notes and published them on this blog. I knew I would be ready to do it again in 2014.
And I did. CascadiaJS 2014 was in Portland, and I bought a ticket and lodging nice and early. Beyond being excited about attending, I had even begun to think I might be able to speak. I had even submitted a talk. It was pretty awful, but that's the first step. 2014 was just as wonderful as the last year - I made sure to thank Tracy and Carter (head organizers for that year) personally, since I knew it was a ton of work to organize something so big and so lovely. (Organizing a conference is kinda like organizing a wedding, every year.) Since I followed the CascadiaJS repo, I was able to observe many parts of the organization process, and contributed some (hopefully!) helpful thoughts for the next year.
So, there you go. I got involved by attending first, providing useful feedback to the organizers, and participating in the community.
I got my tinylab last week; it's a nifty little prototyping board with an Arduino Leonardo and a bunch of embedded components that was funded on IndieGoGo. So naturally I wanted to get Johnny-Five working and start fiddling with the tinylab as soon as possible. Unfortunately, it seems like the hardest part of every hardware project is the grand upgrading of the softwares that must proceed fiddling. Here's the process that worked for me.
- Re-install Node. My Node installation was a few versions old, and somehow npm was missing. So I went ahead and installed Node.js from https://nodejs.org/en/download/. I decided to live dangerously and install the "Current" version rather than the Stable one.
- Upgrade Arduino.app. My Arduino install was older than the Leonardo, so I needed to upgrade it too. I got version 1.6.10 from https://www.arduino.cc/en/Main/Software.
- Upgrade npm packages.
npm outdated showed that several packages (including Johnny Five) were out of date. This required a few rounds of
- Write the Johnny Five code. I checked the excellent Johnny Five docs and wrote this code for the first LED on the tinylab.
var five = require("johnny-five");
var board = new five.Board();
var led = new five.Led(13);
This should make LED1 (on pin D13) pulse on an off. At first I tried using
"D13" to address the LED (since that's what's silk-screened on the board) but it was just
13 that worked.
Here is some tinylab documentation that might come in handy next time:
A while ago, I interviewed for a job with a company that I was absolutely in-love with. I'd been excited to see that they were looking for a front-end developer and I applied right away.
Back to the interview, we'd gone though a few basic questions and the interviewer had moved on to the algorithm questions. It was a little more complicated than Fizz Buzz, but it wasn't too tricky. But I flailed around for a while trying to both understand what the interviewer was asking, as well as trying to logic out the solution. I didn't solve the algorithm easily enough, and I didn't get any further in the interview process.
Why evaluate a front-end developer based on a algorithm? It's such a very small part of the job, and especially over a video conference after a full day of work, and it's the wrong test to get the front-end developer to demonstrate their best. It's like evaluating an NFL kicker based on their tackling skills - sure, they need to do it sometimes, but a proper blocker will always be more skilled at tackles.