As I’ve progressed on my journey toward become a developer, I’ve encountered a strange problem: there’s a surplus of work being presented to me. I don’t mean that in an arrogant or conceited way, so allow me to further explain.
When people hear that you’ve quit school/work/life to become a front-end web developer, not too many people are sure of what that means. It’s then your job to explain that, in the simplest of terms (because nobody really wants to hear what SASS, Grunt, AngularJS or whatever new tool you’re excited about) that you make websites. At this point, the conversation will usually go something like this, “Oh, you make websites? That’s GREAT! I[‘ve been meaning to make a/ I know someone who needs a/ My company needs a] website for a [business/ school/ bake sale]”.
This, my friends, is where I had to make an important decision. I’ve had to say “no”, which is a little more difficult than it might sound. It’s extremely difficult to me because I’ve had no income over the past few weeks while I’ve been going through the HackerYou bootcamp. I’ve had to say no because while I’m flattered that people would select me to do work for them, I feel like I might sacrifice my opportunity to learn at HackerYou by becoming immersed in something other than the lessons and projects. If I’m being completely honest, it’s also usually due to the fact that most people’s budgets haven’t warranted me wanting to drop everything to work on their project (I realize this is a bold statement coming from someone who is more or less surviving on mustard sandwiches right now, but I don’t want to set a terrible precedent for either myself or my freelancing brothers and sisters).
I can usually get around seeming ungrateful for work passed my way by simply telling people that I know that I straight up avoid mixing personal and professional life at all costs because it can get super weird super fast. This is usually enough to explain myself, and everyone that I’ve told this to is very understanding, and I usually also have a handful of other people I can recommend in lieu of myself.
This is, as I understand it, a very Jerry Seinfeld approach to saying “no” to people. Why Jerry Seinfeld? In his latest show, he talks about how he’ll meet people in the street and have a quick conversation with them, ending it with the phrase “it was great to meet you”. That phrase it pretty much the most well-crafted phrase to essentially tell someone “this conversation is ending now”, while still giving them a compliment. What a guy. Class act all the way through.
Code is one thing that I knew that I would be developing my skill set in by coming to HackerYou, but I’ve found that I’m developing a whole new set of abilities that I hadn’t planned on: my people skills. These are the kinds of skills that you can try and teach all you want, but the truth of the matter is that you just have to socialize a lot, and put yourself in situation that might be uncomfortable at first, but let you grow immensely.
So, thinking that I might have a shot at understanding some of the material, I went to the meet-up with a few pals in tow – Wisam (programming whiz, and awesome dude) , Burger Boy Matty M, and Jonny James (handsomest man this side of Yonge St).
The task assigned to us (“us” being the “total beginner table” – shoutout to our table-mates Connie and Tobi, you guys were awesome!) was to complete four tasks, and then collectively come up with some kind of project using Node between the 6 of us. Seems easy enough, right?
Well, the tasks jumped from “wow this is not as hard as I thought it would be,” to “… I don’t even know what these words mean”. Jonny and I paired up and tried to tackle the problems, which was my first time doing a paired-programming exercise, and I’ve gotta say that I really enjoyed it. We ended up only completing two of the four problems, but it was a really great process of brainstorming, coding, troubleshooting, repeat, and eventually triumph. Many fist-bumps were had. I even got to explain for loops using my nacho analogy (ask me and I’ll go into more depth. Also, I want it to be publicly known that I love nachos).
Over the past few weeks, I’ve been learning a lot of little tricks and tips from the instructors and mentors at HackerYou – most recently SASS (which I prefer) and LESS, which are CSS pre-processors. To abreviate: they make writing CSS much easier and more awesome. All this is to say that my workflow has increased exponentially since taking the full-time bootcamp course. So I thought I’d detail a few of the things that I’ve stepped up since taking the full-time course, something that every dev should be looking to do to streamline their workflow.
First and foremost, we need to start with what text editor you’re using. Personally, since I’ve started working in HTML and CSS I’ve used nothing but Sublime Text, and I have nothing but good things to say about it (heck, I even paid for it!). I used version 2 for a long while because I hadn’t upgraded my OS, but I eventually caved and upgraded both my OS and Sublime. I didn’t notice a huge difference, but one slightly annoying thing was that I had to re-install all the packages that I had on my Sublime previously. Speaking of which…
This, to me, is one of Sublime’s biggest draws – the ability to create, modify, and install packages created by other users or yourself. One of the most popular ones is a package called Emmet, which you absolutely must install if you’re using Sublime. Sublime will still work if you don’t install Emmet, but it’s a bit like buying a Ferrari and only driving it in the parking lot of the car dealership. People have blogged about all the crazy awesome shortcuts and tricks you can do with Emmet, and the folks at Emmet have actually prepared a handy-dandy cheat sheet for you to reference. Resident web ninja/tool junkie Wes Bos is currently writing a book about how awesome Sublime Text is, and has a few blog posts about how you can visually tweak Sublime Text to help you out (post numero uno, post dos).
Alright, this one may be a little far fetched, but hear me out: you should think about getting an external monitor. I know, I know, it seems a little excessive, but I swear it’ll improve your workflow. I thought having a second monitor was excessive, until I found myself having to constantly have to write code, save, tab over to my browser, refresh, look for the change etc. I know that all these things can be automated to keystrokes, but that’s still time (a LOT of cumulative time) that you could be coding and not tabbing between windows. So after a while, I started looking into getting another monitor. Turns out they aren’t as expensive as I thought they were (mind you, they’re not cheap, but they’re not the $500+ I thought they were for a decent one).
You might even be able to score a good one off Kijiji or Craigslist for cheap – but if you’re going this route make sure that you get a chance to see it actually on before any money exchanges hands, dead pixels are the worst. Even if you’re not going the preloved route, I definitely recommend seeing the monitor actually functioning, and I’d also recommend going to a site like Unsplash, so you can see how the colours and resolution are. Sometimes a monitor looks like it’ll be great, until you try and look at a high res picture with intense colouring and it looks like you’re staring at a crayon drawing of a potato. No bueno, my friends. No bueno at all.
This is my current setup:
In the top monitor I’ve got Sublime going, and I’ve split my window in two – one half has my HTML, the other has my CSS. The laptop below has my browser, onto which I’ve installed a plugin called Auto Refresh Plus which I set up to refresh every 5 seconds – just one more thing that I’ve set up to expedite my work. I’ve also got an external keyboard and mouse plugged in – without it the setup felt extremely uncomfortable and I was working with shoulders hunched up and ruining my back. The mouse is essential because using the trackpad is awful for your wrist, and I (for some crazy reason) don’t want to end up with carpal tunnel.
This is a tricky one, as it’s difficult to do because you’re building the site on your computer and testing it locally. I know that this may not be the most recommended method, but what I like to do is create a directory on an already existing site and test the site on my phone, or a friends iPad if available. As an example, proudfeet.io/wheresdrake takes you to the site that I was testing my Where’s Drake app on before I went and bought my own URL for it (full disclosure: this app is not responsive at all, and probably won’t work properly on your phone). I know that a lot of you might be thinking why I don’t just do this by resizing the browser or using some of the dev tools in the browser. While those are all great options, and generally what I do before I put the final touches on, nothing really compares to the feel of using the website on your phone. What looks great on your screen might not translate the way you thought it would on an actual phone – text sizes may be too large, something might be too far adjusted to the right etc. Mobile site are all about the feel and while resizing the browser will get you pretty close, it’s still no substitute for the real thing. Here’s me testing out my latest HackerYou project on my phone, it feels good to know that the designs don’t just work in theory, but I now have definite proof that they translate well to the device.
Until next time, stay SASSy (womp womp)… I’ll see myself out.
I was struggling to think of a way to implement something to do with mouse movement, when I was told about the JQuery UI Draggable and Droppable, which somehow led me to thinking about searching. Then, like a lightning bolt it hit me – Where’s Waldo! For those not aware, Where’s Waldo (or Where’s Wally in the UK) is a children’s book game where you have to find the namesake character in huge image filled with many diversions and distractions.
My first attempts at creating the “spotlight”/”lightbox” effect were by and large huge failures. That, however, is not to say that they weren’t valuable exercises – I feel like you learn more from your failures than you might from your successes (don’t be afraid to try something new!). Nevertheless, it turned out that creating a circular div with the image of the Where’s Waldo page with a giant div of all black spanning the whole screen would (somehow) not create the effect I was looking for. I don’t know why I thought this would work, but it most definitely did not in any capacity. Back to the drawing board.
After playing around with a couple more options (including creating a giant black image with a circle cut out of it in photoshop – this probably would have worked, but I was convinced that this effect would be possible using CSS), I was brought back to my old friend background-attachment: fixed. Most people use this declaration on images when they want to give the effect of another div scrolling overtop of it on their web page (an example of such on my own website), however, it turned out to be exactly what I needed to remedy my situation. Remember: this property essentially makes the image stationary, regardless of whatever else is happening on the page. Here’s what my CSS looked like at this point:
Boom shakalaka. One important thing to note was that I put a 10px border of solid red just to see where the div was actually positioned on the page before I started tinkering with it’s position (which was absolute and then adjusted the top and left – don’t use margin here, you’ll move the whole div and the “spotlight” effect won’t be apparent)
Next, we’re going to need to access the JQuery UI, which allows us to another set of plugins built into JQuery. If you’re familiar with other programming languages, think of this like importing a module such as math or antigravity. This snippet for this is available once you’re viewing one of the plugins, I got it from looking in the head of Draggable, but can be a little tricky if you don’t know what you’re looking for, so here’s the snippet: <script src=“//code.jquery.com/ui/1.10.4/jquery-ui.js”></script> . Paste this snippet in the head of your document, and we’re ready to rock.
For the sake of brevity, I’m just going to cover using Draggable, but you can take using Droppable (which has Draggable already built into it) pretty far by setting a target (such as on top of Waldo) and have the script do something when you drop your spotlight on him – an example of which is up on my Codepen.
Not long after I finished the Where’s Waldo example, my good friend Vanessa Merritt showed me the infamous video of Drake lint rolling his pants. Since we live in Toronto, and pretty much anything involving Drake and the internet is nothing shy of hilarious, one thing led to another, and, well… Where’s Drake was born. My mom is very happy that I dropped out of school to make this.
First, let me preface the rest of this by saying that I straight up ripped this technique off from Christina Tosi of Momofuku Milk Bar, but I’ve added a few tweaks to it, making it slightly more my own, although it is quite true to the original.
Sometimes, when I need a mental break from coding, I bake stuff. This is one of those times.
I first came up with this when trying to come up with a new dessert for the restaurant I was working at at the time. I was trying to find something that would add texture to the dish, while still being packed with flavour – I find that a lot of “crumb” components in desserts lack flavour, and I’ve always tried to make sure anything I put on a plate has a function. I also wanted something playful, and something that people would recognize. After a little brainstorming, Captain Crunch came to mind, and I also thought that corn was a flavour that was constantly underplayed in the pastry world.
Once I decided upon Captain Crunch, I looked through a few of my cookbooks until I stumbled upon this technique from the Milk Bar book. I knew immediately that the “crunch” technique needed to be married with Captain Crunch (I mean, come on – it’s right in the name!). Now, how to make it my own?
A quick look through my pantry would answer that for me. Korean red pepper flakes – a product I’d taken to dousing on more or less everything I eat – stood out as another flavour that was criminally underplayed in the pastry world. My logic went something like: “Captain Crunch is made from corn, corn and dairy is delicious, corn and chilies are amazing… so mixing all three must be super amazeballs!” I merged the two and a star was born.
The only problem with this recipe is that I never got to actually use it – all the other cooks and I ate it all as a snack before it ever even touched a plate. Now when I bring it out, it’s kind of a special occasion, and it always takes less than an hour before it’s devoured (usually as a topping for sundaes or as a garnish on top of a slice of cake for some texture). Anyways, without further ado, caramelized Captain Crunch:
Recommended listening: Blu – Good Morning Neighbor
Mise En Place
- 130g (2 1/3 cups) Captain Crunch
- 40g (1/2 cup) skim milk power
- 30g (2 1/4 tablespoons) caster (white) sugar
- 2g (1/2 teaspoon) salt (use kosher salt if possible)
- 6g (1 tablespoon) Korean red pepper powder (optional – you can omit or add more if you like)
- 100g (1/2 cup) oil (I like using grapeseed, but you can use whatever you want, as long as it’s not olive oil)
- Preheat oven to 275°F
- Combine all the ingredients except for the oil in a bowl and give them a quick toss to disperse evenly
- Add the oil and toss/mix, taking care to break down the Captain Crunch as little as possible (ideally not at all), and all the pieces are coated evenly (something like this)
- Spread out in an even layer on a sheet pan, and bake in your oven for 12 minutes – rotating the pan halfway through the cooking process
- Once the 12 minutes is up and your “crunch” is looking mighty tasty , let it cool for at least 10 minutes (this is the hardest part of the whole recipe – resist temptation)
- Eat, enjoy, and contemplate the finer things in life
Well, today it finally hit me: I just quit my job and dropped out of school to become a web developer. You’d think I’d be terrified (maybe I should be), but I’m more excited than anything. Coming hot off the heels of HackerYou‘s part-time web dev course, I feel like I’m at a stage somewhere just passed “web n00b”, but not quite at “l337 web ninja” just yet. Hopefully over the next 9 weeks I’ll end up closer to the latter, but until then the internet will just have to deal with me stumbling through the web.
It’s been an interesting first few days at the full-time bootcamp, there’s a distinct sense of community already within the first few days, which is something that only formed in more or less the 11th hour of the part time class. I think it’s mostly due to the fact that all of us are more or less fish out of water, which is not a bad thing at all, and I’m definitely embracing.
So far, there’s been a lot of review – which, while it may seem boring, has actually been amazing! While I was doing the part-time course, I was constantly trying to juggle between working two jobs, school, and coding in class or the few precious moments that I had free time. As you can imagine, there wasn’t much time to really absorb the content – now I feel like I can really process the content, fix any bad habits, and help out with other people who might not be as exposed this web voodoo as I’ve become over the past few months – which is rewarding in it’s own way.
Since we’ve got our first project coming up at the end of the week, I decided to take a look at the first project I did for the part time class. It’s hilarious. Hilarious in the “looking at pictures of yourself in middle school” kind of way – a little cringe-worthy, but still awesome. If nothing else, I can say that I’ve made progress away from being that clumsy with my code in the past few months, but I’m still nowhere near where I’d like to be. Even my final project, which I finished just says ago, has a number of flaws that I’ll most definitely touch up before I pitch it to the intended client.
With that said, here’s a list of things I’ve picked up along the way for anyone just getting web dev to consider:
- Don’t try and design while you code – This is a terrible habit that I have, and it makes absolutely no sense as to why I picked it up . There are plenty of free online resources to give you templates, use them, but don’t copy the code. Ever.
- Good photos make your website look infinitely better – There are plenty of online resources like Unsplash that give you awesome photos for free. Hire a photographer if you need head shots or specific photos taken. Whatever you do, you need to promise me that you will never ever ever use a photo from your phone on a website.
- More complex ≠ more awesome – Have the content speak for itself. Too much information can be disorienting and lead to terrible user experience, as well as leaves a large margin for messy code
- Take a break – I’ve encountered a few times where I can’t figure out what’s stopping my code from looking the way I want it to. Thinking I could somehow brain-muscle the code into working, I would spend hours trying to tweak it to get it to work. When my smarticles had been exhausted (I have precious few), I’d end up going to the gym, where, of course, the answer to my problem would come to me (usually mid-squat or some other equally unfortunate time)
- Learn to say “no” – This one is probably the hardest to learn. Telling your friends that you can’t come out, or your significant other that they can’t come over, because you’re “in the zone right now” or “are really trying to nail floats” goes over about as well as trying to tell people that rollerblading is cooler than skateboarding (I tried this when I was 11 – 0/10, do not recommend). Unfortunately, part of getting awesome at anything is actually taking the time to get awesome at it in the first place, and that means that at times, it might eat up other parts of your life. Tough break, kiddo.
Anyways, I feel like that’s probably enough of my ramblings for the evening. I’ll try and keep this thing updated as often as possible, until then – keep your stick on the ice.