https://gist.github.com/mattbarackman/82b1712add45ceffa8ffe56f81b8bcc2
$LAYYYTER
tumblr dot com
Jules of Nature

#extradirty

Andulka
cherry valley forever
AnasAbdin
Xuebing Du
NASA

Love Begins
Cosimo Galluzzi
dirt enthusiast
Keni
Cosmic Funnies
he wasn't even looking at me and he found me
we're not kids anymore.

⁂
TVSTRANGERTHINGS
todays bird

Origami Around

seen from United States
seen from Germany
seen from Italy
seen from United States

seen from Malaysia
seen from United States

seen from United States

seen from Türkiye
seen from United States

seen from United States

seen from United States
seen from United States
seen from United States

seen from United States
seen from United States

seen from United States

seen from Australia
seen from United States

seen from United States
seen from Malaysia
@mattbarackman
https://gist.github.com/mattbarackman/82b1712add45ceffa8ffe56f81b8bcc2
Week 1 Day 5: Hacking our Brains
It’s finally the end of the first week and we capped it off with a mini-lecture from Sherif “Sheriff” Abushadi. I am in so much awe of this man. He has a way of explaining concepts in a way that is absolutely mesmerizing and has taught us so much about how to maximize our learning.
For starters, he can always pull out these amazing metaphors out of thin air. In our session, he was explaining to us that not having the proper vocabulary to describe your code is like trying to write your thoughts on a whiteboard with a marker that’s out of ink. You can make the shapes for words, but it’s really difficult to get your point across. Now, every time that I look at a whiteboard (and they’re everywhere) I’m going to remember to practice my vocabulary.
He also talked about envisioning arrays as halves of egg cartons. Now that I’m thinking about it, he mentioned at the beginning of the week that he’s a visual thinker and learner. I’m not sure that I am, but using my visual processing to reinforce concepts is an awesome tactic that I’ll have to work at.
Sherif also drops tons of other knowledge bombs related to cognitive science and learning on the regular. He’s talked about removing your super ego (aka your judge) and acting more like a child. That without your super ego to tell you that you’re stupid or a shitty programmer, you’re not inhibited about asking clarifying questions or trying problems that you might otherwise think are too hard to solve. And that thinking you’re an amazing leaner or being told you’re an amazing learner has scientifically been proven to help it become a reality.
And that your brain cells are actually much more malleable and able to learn when you’re relaxed and having fun because they’re coated with dopamine. Or conversely, when you’re in fight or flight mode, you’re so worried about the here and now that you’re less able to form new memories for the future.
And there’s much more that I could go on about.
As I’m thinking about these principals and the DBC experience, I’m beginning to see how much of it has been built on these principals. As I continue on I’m going to continue to try and keep a positive mindset and keep my super-ego at bay. I’m also going to try and encourage my peers throughout the day and inject as much fun as I can into it.
Week 1 Day 4: Body Movin' Body Movin'
When they say DBC is intense they're not kidding. I'm only four days into it and my life has already been map.reduced to DBC. All but about two of my waking hours each day are in the DBC office and its making me a little stir crazy.
To combat the intensity and cabin fever, we attended our first session of yoga today at the YMCA around the corner. For boots in their first three weeks, yoga attendance is mandatory.
Learning programming is such a mental exercise, that it's easy to totally neglect your body. I've been so focused on coding and solving challenges that I've been forgetting to eat and drink enough water. Even time seems to disappear. Four hours can go by without you realizing.
Yoga really helped me get out of my head and re-inhabit my body for a little while. It's going to be tough with everything going on, but I'm going to try a lot harder to listen to my body this next week. I don't want to burn out before the second phase even hits.
Today, we started to learn about Classes and took our first crack at some exercises that involved an existing codebase. One of the challenges was to make a rudimentary racing game run in the terminal and the other was to build a version of Boggle that randomly generates a board, shuffles, and checks to see if it contains a given word.
The logic was a little tricky at times, but I felt pretty comfortable with the classes. I think the proudest moment of the day was when my partner and I were solving the Boggle method that checks if it includes a given word.
As part of our solution, we populated our Boggle board with an array of Dice instances and we wanted to join the dice faces in a given row into a string. We then used String#match to check if it included the given word. One problem we ran into was that it was trying to join the actual Dice object, not their presenting faces. This was a real thorny problem, for reasons I won't get into, but I came up with an out-of-the-box solution (at least for me) that involved writing a custom Dice#to_s method which returned the presenting face as a string. With that new method, calling join on the array of Dice instances created a string of all their faces!
You obviously shouldn't be writing over existing methods carelessly, but I think in the context of this challenge it did just the trick. I'm stoked that I now have some actual experience with implementing this kind of thing. It will forever be in my toolbox and that's awesome.
Pick 3 2:
SizeUp is an awesome little OSX plugin with hotkeys for quickly snapping your current window to fill exactly half of your screen. It's great for placing you terminal and text editor side-by-side.
When writing recursive functions you can throw an unassigned gets at the top of the function, so you can manually run through each recursion in the editor. Place a puts with your variables just before the gets and you're cooking with butter.
Week 1 Day 3: Channelling the Growth Mindset
It's 10:30pm on the third day of DBC. I've just finished dinner (let that sink in, haha) and I'm sitting down to write today's blog post. Unbelievably, I've made it three consecutive days of blogging. Hopefully, it becomes a habit.
Shereef (aka "Sheriff"), the not Shereef Bishay one, gave us a little chat this morning on a static ability mindset vs. a growth mindset. In the former we believe that we were born with a certain level of smarts and specific set of talents. In the latter, we believe that we can do whatever we set our mind to and that being confused is an acceptable and necessary step to mastering a new talent.
One aspect of this growth mindset is that you're constantly pushing yourself outside of your comfort zone into a place where you're confronted with challenges you can't solve. That is, until you can solve them.
Over the past two days, I don't think I have quite been pushing myself hard enough. I've been content to finish the "core" problems, but I haven't pushed myself to really go after the stretch challenges.
Today, though, I partnered with a DBC student who is repeating the first three weeks of the program. He said he already knew all the answers and basically said he'd sit back and help steer me back on course if I started to stray, but otherwise was going to let me do all the driving.
Today's topic introduced recursion and explored the differences between iterative and recursive methods. I've had some prior experience with recursion, so I once I dusted off the recursion circuits in my brain I was able to grok the concept relatively quickly.
The afternoon session also introduced Binary Search and we were tasked with writing an implementation of it. Our instructors, Brick, mentioned that it "smelled" recursive so I gave it a go with recursion. I had a ton of trouble getting it to work, but finally realized that I could "store" stuff between calls if I introduced an optional parameter. I looked at some other solutions and some of the iterative ones looked really elegant. Didn't come across any super clean recursive ones, but I'll look a bit harder tomorrow.
I finished all the core stuff about an hour early, so I decided to push myself and try something that definitely seemed out of my comfort zone. My partner mentioned that one of the day's stretch challenges was super hard and very few boots had ever solved it. Intrigued, I checked it out and it looked incomprehensible. It's a wild combination of what seemed like cryptography and reverse engineering, where we are given a seeming random sequence of arrays and are asked to reverse engineer the algorithm that produced it from a given input.
Rather than abandon it for something I was confident I could solve, I dug in with my partner. We started by just staring at it and looking for any trace of a pattern. It didn't come all at once, but we began to identify subtle patterns that we could slowly begin to build upon and fit together. By the end of the hour, we hadn't solved it 100%, but I believe we cracked much of the pattern. Over the next week, I hope to work more with my partner to finish cracking the pattern and translating it into code. If we don't get it, we don't get it, but I'm really glad that we took on something that seemed impossible and were able to do more than either of us thought we were capable of.
Pick 3:
In IRB, you can enter "require 'filename' and have access to all the methods of your file in IRB. It's a good way to play around with methods and sub-methods as you're writing them.
Size 18 font is MUCH easier to read than size 12 font in Sublime. (You can easily change the size of your font by editing the "font_size" attribute in Settings - User.)
Recursive functions tend to take up considerably more time and space when running, but can sometimes yield very elegant solutions. The performance issues can sometimes be mitigated by caching some return values of calls to your recursive function.
Week 1 Day 2: Settling In
Two days in and I'm already starting to feel way more at home. More at home with the early mornings and late nights, more at home with my peers, and more at home with the endless challenges.
As was the topic of my last post, I had a bit of mania with yesterday's challenges. I couldn't help but take control and jam through the challenges with the speed and individualism I was accustomed to. It wasn't the programmer I wanted to be, and I knew something had to change.
Well today, we doubled down on the topic of feedback with a morning lecture about giving and receiving it. Afterwards, I chatted again with my previous partner and he reiterated (nicely) that I had been a little inattentive to his needs (or in my estimation, a douche).
So today I made a deliberate effort to slow down and was remarkably able to bring an almost meditative mindset to the day's challenges. I failed yesterday, but today it just kind of clicked.
I'm not sure why, but I think part of it was that having finished the challenges yesterday, I felt today's would be manageable. This may have removed some of the feelings of inadequacy or fear that may have been lingering in my sub-conscious.
Without as many doubts, I may have been able to shift the focus from myself and become more compassionate and aware of my partners' needs. For example, during my first pairing session, my partner was rushing through the assignments and making lots of simple typos. In the spirit of feedback, I suggested the he seemed rushed and might benefit from slowing down. I also sensed this pressure to rush may have been coming from me, so I assured him that I would be sincerely happy to spend all morning on the first challenge if that's what he needed. After that, the typos all but stopped and our chemistry really improved.
By shifting my mindset from one of fear and inadequacy to one of empathy and confidence, I was able to not only be a better team member, but a better programmer. Without the stress I was able to think more clearly about the assignments at hand. And by focusing on my peers, I was better able to listen and pick up valuable bits of knowledge from them.
I feel lucky to be at a place with the material where I can, at least for the moment, keep relatively calm and productive. I know not everything in the next nine weeks will be so easy, so when I'm feeling down or overwhelmed (maybe tomorrow for all I know), I'll hopefully be able to remember the good that remaining calm and compassionate can bring.
Pick 3:
Beginning in Ruby 1.9.X, the Hash data type preserves the order that the key-value pairs are entered in. This means that if you use each to iterate over a Hash it will do so in a predictable order. My partner and I made use of this behavior in our method for converting roman numerals. In earlier versions of Ruby, the Hash is unordered, which is, I believe, how hashes work in most other languages.
When using RegExp, you can use parentheses in the RegExp to create ad hoc groups (backreferences) that are assigned to integers. These integers can be used kind of like variables in functions like String#gsub and are extremely helpful/powerful when working with RegExp.
The method Enumberable#sort_by allows you to sort Enumberables by arbitrary attributes. The normal Enumerable#sort uses either lexicographic or numerical ordering, so the #sort_by method is a lot more flexible.
Week 1 Day 1: Slipping into the Driver's Seat
It’s 8:30 pm on the first day of DBC. I’m largely done for the day and am currently on BART, rumbling under the bay towards by apartment in Oakland.
One of the last few things I need to do is finish this blog post. I’ve set a goal for myself to write one every day to document my journey and in order to stay on top of it, I’m limiting my writing time to just 20 minutes a day. My ride home on BART is just about that long, so here I am trying to make it happen.
Overall, I think my first day went really well. It was harder and longer than I anticipated, but I’m still feeling confident and motivated.
The first half of the day was dedicated to ice breakers and logistics. I don’t want to ruin the kick-off experience for future boots, but it was a super fun and energetic welcome. DBC knows how to party (and is apparently on thin ice with it's neighbors, so no jumping allowed.)
We spent the afternoon pair programming on our first day’s exercises. For the uninitiated, pair programming is where there are two monitors and two keyboards but only one computer. The idea is that you can transfer knowledge more quickly if you’re coding together. Even though we’ll be coding on our own after hours, we’ll be pair programming almost 100% of the time we’re on the clock. After spending so much time coding alone, it is definitely going to be an adjustment.
First off, I loved my partner. He’s a super smart guy and had some amazing insights into the challenges we were trying to solve. The problem is that we had agreed to switch off “driving” after every challenge, but I managed to take the driver’s seat by the end of each exercise. I didn’t do it on purpose, but I realized that I like to think with my hands. I like to write something out and see what it does -- to write bits of code and see them in front of me, before I try and wrangle them to do what I want. My partner said he didn’t mind (and I apologized profusely), but it’s definitely a habit I need to break. I’m literally going to sit on my hands tomorrow if I have to.
One excellent part of DBC is that we’re expected to provide feedback on our partner after each pair programming session, so we’re not just learning to code, but we’re learning to code well as a team. Again, I want to be a great team player.
And crap. I’m already over my time limit.
With that in mind, I want to introduce my daily "Pick 3" before I go. The idea is that I may not have the time or energy to write a long blog post every night, but I'll at least be able to write down a few things I learned that day. Hopefully, it will give me a nice list to refer back to and feel proud of once this whole shebang is over with.
Today's "Pick 3"
Until loops can replace While loops with a negative condition, which is analogous to how Unless can replace If statements with a negative condition.
Evaluating ruby code in Sublime using cmd+b can provide funky results and is NOT recommended.
Using the break in Ruby can also do unexpected things and should be avoided.
And So It Begins...
Tomorrow morning at 8:50 am, I'll be arriving at the Dev Bootcamp office in San Francisco, coffee in hand, to begin my initiation into the world of web development.
It's been almost nine months since I decided to apply to the program and five months since I was accepted.
The wait has honestly felt like an eternity and now that the moment is finally here, my enthusiasm is palpable.
It's not just my moment though. Tomorrow also marks the intersection of my life with the lives of sixteen or so complete strangers. Strangers, save our shared determination to learn and thrive in a new profession. And, who hopefully will become new friends with whom I can lean on and celebrate with throughout this transformative experience.
It's impossible to know what the future will bring, but I do believe I'll look back at this moment and see it as a major crossroads in my life. I was good at my old job, but it wasn't something that I loved nor was it something that I wanted to master. Web development, on the other hand, is something that excites me, motivates me, and is a career that I am certain I will totally kick ass at one day.
But that day is not today. Today, I'm hopeful but I've barely scratched the surface. Tomorrow, I'll be a little bit better. And I'll be a bit better the day after that.
Nine weeks are going to fly by before I know it. I don't know how good I'll be when this experience is over, but I'm excited to find out. This experience has been described to me as the most intense learning environment I'll ever encounter and I'm going to do everything I can to take advantage of it.
Inspired by the beauty and promise of Tesla's Model S, filmmaker Jordan Bloch took it upon himself to make his own advertisement. The result, "Gallons of Light," is both gorgeous and compelling. Tesla needs to hire this man.
Jordan Bloch:
As I looked around the store, my eyes wandered to plasma screens showing footage of the Model S. Frankly, I wasn’t impressed. Where was the cinematic flair, the story, the emotion? I knew I could do better.
I'm an Open Source Contributor!
Today, I took a small but (at least personally) significant step into joining the open source community.
I was watching a Treehouse CSS tutorial on web fonts earlier in the day and learned about how to import a downloaded font package into a web project.
Unlike Google Web Fonts which hosts the files and provides a streamlined way of accessing them in your project, adding a downloaded font package requires a little more work. Google Web Fonts is great, but why limit yourself when there are tons of other resources for finding beautiful web fonts?
Here are a few to check out:
The League of Movable Type
Font Squirrel
Font Spring
To add these custom fonts, you must first add the font files to your project directory, then create a custom font-face in your CSS file. This makes your font-family accessible in the rest of your CSS. The difficulty lies in that there are many specific rules to add when creating the custom font-face, which I knew I would have trouble remembering. Rather than reference the tutorial whenever I needed these rules, I decided to create a custom snippet for Sublime Text 2.
This way whenever I need the proper code in a CSS file, I will be able to just type "font-face", hit tab, and the correct code will auto-magically appear.
Awesome.
So, by referencing this Tuts+ tutorial on snippets, I was able to create the snippet you see below!
Code
This is not only going to be super helpful for me, but for others as well, as I published my snippet as a public Gist on Github.
I've gotten a ridiculous amount out of the open source community since I've started programming, so it's nice being able to give back in this small way.
It's been a little intimidating given my limited experience trying to find a place where I can contribute to a larger project, so this was a low stakes way I could start along that path.
If anyone has any suggestions on where a beginner can start to contribute in a larger way, I'd love to hear them. In the meantime, I'll definitely be writing more snippets and making them public.
Digging Treehouse
I've thought I'd give a quick shout out to the Treehouse team.
Not only do they do an excellent job presenting and testing programming material, but they've nailed the learning experience from a branding and engagement point-of-view.
On first impression, I wasn't quite digging the sets and overly polished performances. They seemed more aligned with the saturday morning cartoon demographic than with the adult programmer.
Still, it's differentiating and conveys a level of attention to detail that I can appreciate.
What really sold me on Treehouse, though, is the narrative that they've brought into the experience.
What I mean, is that they now have an episodic film called The Arrival that you can unlock as you complete challenges. As you would probably expect, the acting isn't stellar, but the story is surprisingly compelling. The little bit of entertainment these periodic shorts bring makes a big difference when I'm plugging through hours of these tutorials.
It also shows the Treehouse team having a lot of fun and gives their people, or should I say characters, more dimension. This transforms the relationship between viewer and instructor in a way that creates more engagement during instruction as well.
I won't share clips of The Arrival because you should unlock these on your own, but I'll leave you with another series of shorts they made which parody MTV's Real World.
The Beauty and the Beast
Over the weekend, I started work on Project Euler. For those of you not familiar with the project, it's a sequence of math problems that require computer programming to solve.
The challenges are also language agnostic -- all that is required is to "solve" a problem is that you enter the correct numerical answer. I started on these problems primarily to practice my Ruby skills, but what I've found is that solving them is just as challenging from a mathematical point of view.
For example, it started out rather simple with a FizzBuzz type challenge, yet by the fifth problem it was asking me to find the "smallest positive number that is evenly divisible by all of the numbers from 1 to 20".
This is where things began to get interesting.
To explain, up until this point I had been employing a brute force method to solve all of these problems. My strategy for this one was to check every number from one onwards until I found the first that was evenly divisible by every number between 1 and N, where N=20. After writing the code, I ran it with N=20 and seemingly hit an infinite loop. It just wasn't completing.
As a quick aside, I've found that in Sublime you can hit command-b to "build" your current code. This command runs the code in your current file and outputs the result in a window at the bottom of your screen. This saves you the step of pulling up the command line and typing something like "ruby filename.rb".
Getting back to the challenge, I tried running it again with N=10 and it finished in 0.1s with the expected output. It seemed to be working correctly, so I tried it again with N=20 and waited to see if it would finish.
It finally did, but it took almost two full minutes to complete. Woah. That extra ten digits made a huge difference. Not only does it have to potentially divide each number by twice as many divisors, but more importantly, it has to try exponentially more numbers until it reaches the correct answer.
Fortunately, Project Euler allows you to look at other solutions to each challenge after you pass them (which my solution did).
As I expected, there is actually a much more efficient method to solving this problem and it doesn't require any programming at all. I can't explain exactly why it works, but it involves finding the prime factors of each divisor and calculating the product of a certain subset of them.
My takeaway from this whole process is twofold.
The first is that different solutions to the same problem can have hugely different efficiencies as the input grows. In programming, I've learned this efficiency is referred to as the Big-O of a function. The actual notation is something I am still learning and will try and address in more detail in another post. In very simplified terms, though, it describes whether the output grows linearly with the size of the input or exponentially.
This post is a great introduction, but even with it, I still had trouble reconciling my function with the examples it gave. One of these days, I'll try graphing a series of inputs vs. outputs to get a better idea of where my function falls.
My other takeaway is that there are at least two modes of approaching a programming problem. One is a brute force method which is typically easier to construct, but sometimes horribly inefficient. The other involves taking a step back, and thinking about whether there are any insights you can apply to make your code more efficient
At this point, my first goal is to write functioning code. Even a brute force method that works is a win. Per my previous post, I don't want to get so hung up on finding the perfect solution that I'm not making progress. That said, moving forward I will stay mindful of the efficiency of my code. This means thinking more deeply about each problem and comparing my finished code to other solutions whenever possible.
I think a lot of programming is pattern recognition and the more patterns I can train myself to recognize the more efficient my code will become.
Overcoming Obstacles
This past weekend, everyone in my "Red Admiral" cohort of DBC was given our mid-point assessment. It was the last hurdle to clear before being fully accepted into the program and I'm happy to say I passed.
They didn't give much feedback, but I felt that my performance was really solid. I'd love to share my code, but I'm not sure that they want the problems available to future boots.
At this point, I'm feeling like my Ruby skills are getting pretty solid, but I don't want to get complacent. DBC advised not to move onto learning Rails, until I'm totally solid on Ruby, HTML and CSS.
I'm currently hosting my personal website using flavors.me that has a WYSIWYG website editor. I'm not sure it would reflect too well on me when I'm applying for jobs to not have built my personal website myself. So building that out is going to be one of my goals for the next month.
I'd love to use Rails, and I'm tempted to start the project now, but given DBC's advice, I don't want to get ahead of myself.
So for the next few days, I'm going to be practicing Ruby using Project Euler and will be reviewing HTML/CSS tutorials on Treehouse.
Maybe once I've have a better handle on HTML/CSS, I'll begin to work on the layout/design of my website.
One of my struggles has been that I don't want to start a project, only to realize that I'm not doing it with best practices and will need to start over.
For example, I want to use some sort of CSS grid system and I want to design the site responsively. Hopefully, once I finish those tutorials I'll feel confident to dive right in with the knowledge that I can always change things if I have to.
It is a larger anxiety, though. I had the same issue on earlier projects with choosing a database, or a hosting provider, or, in the beginning, a language/framework. It's just hard to shake the feeling that I'm committing to an approach or technology that I might regret.
I need to constantly remind myself that everything I do is going to be a learning experience and I can't let striving for perfection keep me from moving forward.
Embracing the Sublime
The Most Important Tool
A text editor is to a web developer, as a rifle is to a soldier. I'll be using my text editor all day every day for the foreseeable future. I want to be completely comfortable with it, I want to be fast, and I want to know everything it's capable of.
To borrow from Kubrick's Full Metal Jacket:
This is my rifle. There are many like it, but this one is mine. My rifle is my best friend. It is my life. I must master it as I master my life.
Before you master a text editor, though, you need to decide on one. The question of which is best is apparently a holy war among web developers. I asked around and was told to learn EMacs, TextMate, VIM, various IDEs, and countless others. Some even suggested using the super basic, TextEdit, to force me to learn proper syntax on my own. I think the most intriguing option is VIM with it's hyper-efficient layout and promise of speed, but learning that will have to wait until I have less on my plate.
It turns out that Sublime Text 2 is the unofficial text editor of choice for DBC, so I decided to commit to that for now.
Getting Started with Sublime Text 2
I'm not going to give a full argument for Sublime Text 2, or even an overview of its features. It's just too massive and you can learn these better from other sources. I will mention though, that it is extremeley customizable, and therefore powerful, but not all of it's awesome features come out of the box. If this is your first time working with it, you're going to want to watch a video tutorial, like Perfect Workflow in Sublime Text 2, to get a good handle on it.
Having just finished watching that tutorial there are a few awesome things that I wanted to share.
Note: These may or may not be exclusive to this editor.
Command Palette
Compared to browsing the menu, hotkeys are super efficient, but they're difficult to remember. Especially with super powerful programs with tons of commands (see VIM).
Sublime has plenty of features but you only need memorize one hotkey. Command+shift+p pulls up a killer feature called the command palette that grants you access to every sublime feature through a fuzzy search box. This means you only need a vague idea of what you're looking for, not the exact name, nor the associated hot key.
Snippets (Feature)
Snippets are freaking awesome. One of the challenges I've had is remembering a) proper syntax and b) what functions/attributes are available in different languages. Snippets help with both of these things. Snippets are basically short pieces of code that correspond to common code structures. In Ruby these may be case statements, loops, etc. In CSS these may be attributes and their associated syntaxes. In HTML, these might be stylesheet ref links. With Sublime's built in snippets you can start to type out the structure, hit tab, and it autocompletes the rest of it.
You can also use the command palette to search for "snippets" plus whatever keyword matches what you're trying to do and it will offer snippet suggestions. Or you can type "snippets" and the language you're working in and browse all available snippets. This is a great way to remind yourself of proper syntax without having to dig through the official documentation.
Finally, if you find yourself writing similar bits of code over and over again you can create your own snippets and use those instead. It's a great way to practice the principle of Don't Repeat Yourself (DRY) in your workflow.
Package Control (Package)
Package Control is an absolute must for Sublime and is the first package you should install. It allows you to easily find, add, and remove new packages. And by easy, I mean find and install it in five seconds. Without this, you'd need to find the repo for the package and download it to your Sublime packages folder. This may not seem like a drag, but it can be tedious, especially finding the right repo.
Fetch (Package)
With Fetch you can download individual files or directories directly into your current project directory. So if you ever want to add things like Bootstrap, jquery.js, or normalize.css to a new project, again, you can do it in just a few seconds. No more searching for the right file or dragging it to your project folder.
Sublime Linter (Package)
Linting code means running it through a program that checks for and highlights syntax errors. Sublime Linter comes with a variety of linters for the most common languages and constantly evaluates your code for syntax errors. It matches the Linter to the file type, so once you install it the first time, you're good to go. You can also add additional language support as necessary through package control. I know this is going to be super helpful as a novice working with unfamiliar syntax
Emmet (Package)
Emmet allows you to type in shorthand for HTML and CSS which instantly compiles to fully syntactically correct code. It seems like it would be super helpful once you have the fundamentals down, but this won't help me practice so I likely won't be using this at the moment.
The Onion, in all its brilliance, has a series called Onion Talks in which they parody the self-importance of the TED talk series. Despite the extreme vapidity of the talk, or more accurately, because of it, this video turns out to be a very interesting study on how to use pauses and inflection to engage an audience.
Reading, Writing, and Coding
Ever since I got into DBC, I've been itching to get started with the program and the DBC prep materials.
Well, yesterday, they finally arrived and I'm stoked. I'm already digging in.
One of DBC's first recommendations is to try and write about everything that I'm learning. The idea is that it will reinforce the concepts and, presumably, show future employers what I've learned and how well I can express my thoughts.
It sounds like a great idea, but it's also a struggle. As soon as I finish part of a tutorial, I just want to move onto the next thing and keep learning, but writing these posts is really important and I'm going to be disciplined about keeping with it.
All the same, I need to keep this manageable, so I'm not going to cover everything that I've learned. I will try and record explanations for confusing or non-obvious concepts and quirks that I want to reinforce for myself and hopefully help other people with.
We'll see how it goes! Stay tuned.
I can't wait for May 13th!
Dev Bootcamp here I come!
Last December, right before Christmas, I found out that I got into Dev Bootcamp in San Francisco!
What an awesome way to start my holiday break.
While I was thrilled to be accepted, I was less thrilled that my cohort wasn't going to start until May 13th.
To pass the time, I've been working on a bunch of online tutorials and have even checked out a couple web dev meetups in San Francisco.
At Rails SF, Jeff Dickey from TapJoy gave a really excellent talk about onboarding junior developers. As part of that talk, he gave a special shoutout to DBC and the quality of candidates they produce. He added that he had recently hired seven boots from the same cohort! I've read a lot of great things about DBC, but it was really encouraging to see a respected member of the community speak so highly of it to his peers.
At the talk, I also met a DBC alumn named Mike Reiss who gave me some excellent advice about DBC.
He said (and I'm paraphrasing):
The pace of the program is so fast and the coursework is so rich that after the second day everyone is on the same level, no matter how much prior experience you have.
With that, he added that you should do the prep work, but don't kill yourself over-preparing. He said, that the worst thing would be to burn yourself out before DBC even starts.
As a corollary, he said that nine weeks goes by super fast and it is going to be the most concentrated burst of learning you will ever have. So push yourself hard once the program begins to take full advantage of every second you're there.
Well it's not May yet, it's getting closer everyday. Following Mike's advice, I've decided to take a month and a half off before DBC to relax, travel a bit, and focus on the prep materials.
I told my company last week that March 31st is going to be my last day and I couldn't be happier. Advertising has been great, but Web Development is going to be even better.
This would be so cool on my laptop lid.