DrumSensei

betwixt code and music

The Iron Yard

Landing the Gig

or The Big Payoff

This stuff works! I am now a software engineer and have a job that I love. Let me walk you through my basic timeline and process for making this transition. It is possible with some community support and a can-do attitude!

TL;DR - Timeline of Mike getting a job

A few years ago
- Started getting the itch that I wanted to look into other fields. I had used templates to build a few websites over the years, and I really enjoyed it!

August 1st, 2014
- Moment of clarity strikes me that I could definitely be working in a different field the following year.

Spring Break 2015
- A friend from college tells me about his experience leaving the teaching profession. We briefly brainstorm and I determine that I would be well-suited for web development.
- I revisit
Codecademy.com (I had done a short course four years earlier). I get through all of the HTML/CSS/JavaScript modules, taking notes like mad on the things that I need to study more.

Early June 2015
- Phone/Email conversation with a recent grad of the Greenville, SC campus of the code school The Iron Yard (TIY). I ask many questions about the process and am rewarded with helpful, frank answers. He lives in the Dallas area and works as a Front End Developer for a local shop. After some research into The Iron Yard, I excitedly discuss this with my wife. She agrees that I could switch careers and make it work.



Helpful hints from my TIY friend:
  • Go to meetups to meet people and hear the jargon.
  • Learn more JavaScript beforehand than you think you need. (suggested book - Eloquent JavaScript)
  • Start a blog and use twitter.
  • Understand that you will be well-suited for a junior developer role upon graduation.



Mid-June 2015
- Video interview with Aaron Larner for a spot in the "Front End Engineering" class at The Iron Yard-Austin.
- I work out a possible move to Austin starting on the first day of school here in Texas, staying with my friend Dave Reyes in a house that he just bought. (The plan is to come home most weekends, a three-hour drive.)
- After hearing that I was accepted to TIY-ATX, I resign from my teaching job and continue to code every day.

June-July 2015
- I dig into the pre-work for my course at TIY. I go through all of the Codecademy HTML/CSS/JavaScript modules again, taking notes over every section. I learn by writing, so I was putting a lot of code on paper during this time.
- Each day has time set aside to learn code beforehand to make it as automatic as possible for me.
- I go to a few meetups and tell my story to people. They are usually fairly astonished that a band director would get into software development. Overall people are supportive and happy to see a new face. Yay meetups!
- I meet
Chirag at a meetup at his co-working space in north Dallas. Turns out he is a drummer, and his first teacher was one of my best friends from high school. We later discover that Chirag and I share a birthday with each other (and Harry Potter).

August 2015
- Last teaching gig of the summer with a good friend at the University of Texas-Arlington, then officially on to a life of typing on my laptop and making pretty things.
- Sunday before TIY classes start, my 10yo daughter gets baptized. Afterwards we have a family lunch. During this meal I have to get in the car and head to Austin. My wife prepares for her semester of classroom teaching, two graduate school classes, and four kids in four different schools. This was not an easy day.

The Iron Yard - August 24 for twelve weeks
- I make a habit of blogging regularly. I take up the habit of a daily walk each morning. I keep my head down and work hard. FaceTime with the wife and kids each night keeps me motivated to learn as much as I can. (See many previous blog posts about things I worked on in Austin.)



*** Here's where things start
moving! ***



desk-of-mike

Friday, November 13, 2015
- Graduated from The Iron Yard-Austin

Thursday, November 19
- Found out about a position with Call-Em-All in Frisco, TX from Gautum. I met him through Chirag on Twitter (later in person at a meetup). He pointed me to a great site called LaunchDFW.com, which I had been watching every day, but somehow missed this position!
- The company makes it easy to send out automated phone calls and text messages as a broadcast.
Go try it for free! You might find it useful!

Tuesday, November 24
- Submitted an application to Call-Em-All (cover letter, resume, LinkedIn profile).

Monday, November 30
- Call-Em-All sent me a link to do a written interview which I completed a few hours later.

Monday, December 7
- Invitation to a telephone interview with Call-Em-All

Tuesday, December 8
- Hour-long telephone interview with the CEO and VP of Engineering after which I send a follow-up email

Wednesday, December 9
- Received an email with a coding challenge from VP of Engineering - sent it over a few hours later

Monday, December 14
- Call-Em-All set up an on-site interview for me to meet the engineering team

Thursday, December 17

- Tour of Call-Em-All and interview with CEO, VP of Engineering, and the entire engineering team. Loved the team. Great interview!
- Later that afternoon they call back and offer me the job. I accept! One more surprise: they are renting out a theatre on my first day of work to let all employees and their families watch the new Star Wars movie together!

Monday, December 21
9:30am - Official start of new career!

What I did not include above: coding every day, some other places where I applied, learning new things, trying new things, continuing to attend meetups and learning more about the community.

All of this is not to say that everyone switching careers and going to code school can expect similar results. However, a positive attitude and some help from the community goes a long way. Meetups were (and continue to be) extremely helpful to get acclimated to the language of a new field. If you go out and tell your story, then you will also likely meet some people that might end up being very influential to you!

Also, it helps the company that offered me a position is looking for great people that share similar values and attributes. I wanted to work for a smaller company that knew what they are all about; a place where I can get to know the people and have a great team spirit. Whatever you are looking for in a job, figure it out and go for it!

I cannot stress this enough: get outside of your comfort zone and meet new people, learn new things, push yourself further than you thought you could go. You might find that the rewards are tremendous!

The Weeks After Code School

or How to stay focused

Since returning to my home near Dallas, I have been working hard to stay busy. This is fairly easy to do with four children in the house! A glimpse into my post-code school adventure follows...

Back in June I attended a meetup called "Social Coding" (my very first meetup!). It meets at
nod - the North Dallas coworking space on Preston Road. There I met Chirag, who runs the place. Turns out, not only is he a fellow drummer, but his first drum teacher was my best friend Chris from middle school/high school. Small world! After that, my schedule became too full to attend. I was in Austin for code school and coming home each weekend for maximum family time. I got back over there the Friday before Thanksgiving and met even more cool people. I am excited to help out on the project that they are doing!

I also spent a day working at The Iron Yard-Dallas with campus director Caitlin. She is working out of the
Dallas Entrepreneur Center, a coworking space in the West End area of downtown Dallas, while they are getting a bigger campus area organized. Working with her was extremely helpful. I was having writer's block about getting a cover letter written. My versions kept sounding like I copied it off of Google, despite my best efforts. Travis from the The Iron Yard-Austin campus also gave me some helpful hints. These people are brilliant and go out of their way to help out.

The next day I attended a
coffee club meetup in the heart of downtown Dallas. Being downtown two days in a row is enough to make you feel like a grownup! I met several cool people at this meet up that work for the city, work for themselves, work for other code schools, build robots, make startup businesses welcome in downtown - it was a good time. I will attend again.

The week of Thanksgiving came at a good time. I was able to hang out with the kiddos and give them my full attention. I also managed to keep my GitHub streak alive, but just barely! It helped that a couple of coding sessions spilled over past midnight - that counts as two days! I know that stimulus of the coding streak is a bit superficial, but, hey, anything helps!

2015-11-25 11.16.41

We did manage to get away to downtown Dallas as a family. Melissa and I were lamenting that we had never gone downtown much to just hang out. Our remedy - take the train downtown and just wander around. It was a fun experience. Downtown Dallas is really nice!

I have applied to several jobs and have even more in the backlog for further research. In the meantime, I am learning some Angular.js and updating some old projects. I also made
a repository on GitHub with as many of our class's whiteboarding examples as I could find in my notes. This is a good resource of things we did at the whiteboard in front of other humans. I am also going to be updating my drumr app from my final project to reflect many of the features that I wanted to include but were outside of the scope of my two-week timeframe in early November.

I have learned so many new things recently, and my list of people and places to find help continues to grow. Things are looking good for a life-long learner like me.
It has been a good month!

The Iron Yard in Review

or What I learned about me

As I sit and reflect over the last few months of my time at The Iron Yard-Austin, I can make some good observations about myself and my future path. Sure, I learned a lot of useful, technical knowledge, but I also had time alone to reflect and to immerse myself in my studies. Though challenging to mostly be away from my family, this turned out to be a great plan of action in this circumstance.

Mathew children on first day of school
Mathew children heading off to the first day of school - August 2015
(left to right) Stephen - 11th grade, Isaac - 7th grade, Olivia - pre-K, Alexis - 5th grade

I moved to Austin to live out of a suitcase, with the goal of returning to Dallas each weekend to see my family. This year, just like any other, I started school at the same time as my own children, but I would be in another city far from home. The Sunday before The Iron Yard August cohort began, I drove down to move into my friend Dave's spare bedroom. He is a good guy, and we go back a long ways. When I first began teaching my own groups, Dave was my constant percussion companion while he was an undergrad student at TCU, also working to get young people to achieve greatness each day. Over the years, I had Dave come up from Austin to help teach my groups for one week each summer. This was a nearly annual event for over a decade. I love Dave, and he is a good friend to many people for good reason. As a bonus, he is a superb cook who avoids red meat, so I tended to eat pretty well, too! I owe Dave in a big way!

While in Austin, I decided to reboot some personal habits. I am happy to report that I arose each day and made my bed immediately before doing anything else. This was a great way to start the day by accomplishing something. Hat tip to the incredible
Frank Troyka, who alerted me to this life hack when I worked with him at Berkner High School in Richardson, Texas. I also made it a habit to go to bed relatively early, usually between 10:00pm and 11:00pm. This helped me to get up pretty early. I know myself pretty well after all of these years, and, for me, working in the morning after a good night's sleep is very fruitful. Getting up early also let me enjoy some beautiful morning walks. I knew that this would be useful to offset the copious amounts of chair-sitting that programming entails. I was pretty solid at walking several times a week and getting to bed early. I reckon that this helped me to sustain great health and energy for my entire stay in Austin.

So where did I want to go when this training was to end? I had time to think about my other jobs I have had. What parts of the jobs did I like? What parts was I naturally good at and which were more outside of my comfort zone? I love that I have practiced public speaking (of a sort) for years. I have a good knack at talking to a group of people and finding some common ground. This was useful when interacting with teenagers or parents in a meeting. I think it helps that I genuinely like people and find it interesting to learn each person's story. Being around teenagers for all of those years was a great way to learn what would make them tick, which meant I could get to the heart of the matter much more easily with those students.

Working on a unified team was always fun for me, both as a student and a teacher. A group of people moving with velocity toward a common goal tends to have a greater journey and outcome than disparate individuals doing their own thing. Also, as an optimistic person, I enjoy being around a group that is positive and working hard. Surrounding myself with successful people tends to work out better. Like my uncle Ricky always told me, "You are who your friends are." That always sticks with me, and I hope my own children also learn such a useful thing from me!

Some jobs allowed me to maintain the website which were also fun times. I love making things. My mom was a gifted visual artist with a pen/pencil/writing utensil. I loved her art, and our family always encouraged her to pursue it as a career (which she steadfastly ignored; rock 'n roll to the bitter end, alas). The only art of hers that I still have is relegated to a few envelopes or birthday cards that she would hand-draw. I have that same desire and ability within me, but my goofy hands only work for typing and drumming. Hand-drawn art is just out of reach and always has been. As such, the front end developer's job is appealing because it combines logic and art. (I recently read that in the comments section of
a story on medium.com, and it certainly resonates with me.)

Olivia is glad to have Daddy back home
Olivia is happy to have her Daddy back home permanently - November 2015

Now the hard part begins. Learning about JavaScript and self-invoking functions and hoisting and prototypal inheritance was difficult, sure. However, I knew that every day I would get up and head to South Congress Avenue in Austin to get my learning on. Overall, I will work hard to keep a positive outlook. Leadership is all about influence. As a teacher, I was supremely aware of this and took that part very seriously. Moving forward now my path is less clear, so I will keep making my bed, going to bed somewhat early, learning code, going on walks, and trying to improve my skills...and keep my eyes open for chances to use my influence in a positive way.



Final Push

or Finishing the Marathon

Our cohort at The Iron Yard-Austin started in late August on the same day that all public schools in Texas have the first day of school. For the previous two and a half months I had been preparing to head in a different direction. It had been over 15 years since I had seriously set out to study code. The last time I had formally been trained on the finer aspects of programming was in the 12th grade in the mid-1990s. Needless to say, I was a tiny bit rusty.


courtesy of hutchhouse.com

However, after reviewing different sites available online (yay for open source goodness!), my thinking began to transform. It became easier to use the syntax of JavaScript and understand the various built-in methods. My shortcut and TextExpander game began to flourish. For instance, I found myself typing
console.log(); constantly, so typing ;cl on my laptop now produces the same result. Many minutes have been saved the last few months due to little helpful shortcuts like this.

Since I knew I was headed to The Iron Yard in late August, I made plans to head to Austin in July to see the previous cohort's Demo Day. After watching the presentations by all front-end and back-end students, I took notes about what I thought was effective. Also, ideas began to swim around my brain about an app that I could make by the end of my time at in Austin. Though many ideas were conceived for final projects (with help from my bride), I knew that I had to stick to the assignments at The Iron Yard to learn the proper path to front-end enlightenment. Believe me, there was plenty to do with what our instructor threw at us each day without the added nagging of final project thoughts.

The final three weeks of the course are slotted to be final project and some polish and clean up of old projects/assignments. This included planning for the final push and making sure that all ducks were in a row before coding. I took this seriously and didn't write any JavaScript until making sure that my user stories, wireframes, and data models were clearly instantiated in my mind. After going through a hackathon with all three classes (front-end, back-end, UI design) and doing a group project with all 16 members of the front-end class, planning for the project is certainly the most important aspect.

So...today is the day that we present our completed projects (well, this version, at least) to the staff here at The Iron Yard-Austin. They convene and let us know if we get the thumbs-up to confidently tread into Demo Day. My app is working well and looks pretty good overall. Hopefully things go well for everyone in all of our classes!

Approaching Destination

or Catching Up

I now find myself in week 11 out of 12 in my studies at The Iron Yard-Austin. Much has happened recently, so what follows is a quick recap of the past few weeks since last I updated the web log.



Week 9 - Week 11

Whiteboarding
We began to practice whiteboarding in class in front of the entire group. I went first and was charged with this task: create a function using vanilla JavaScript that, given two integers, returns the greater of the two. All went smoothly and quickly. I wrote down some test cases like [1,2] or [2,20] or [a,3] and made my way through it fine.

Then I realized that I had not named my function...and I thought about it with everyone watching me...and I could not remember how to name a function, how to declare a function in JavaScript - which I have done for MONTHS now dating back to last March when I began studying this wonderful language. ME - a person who has used a whiteboard as an extension of my teaching brain for many, many years. I froze when confronted with that small task. So weird.

To work on this, I started staying later than my peers and erasing the board and going through similar problems while muttering (sometimes even incoherently) to myself. I am getting better at whiteboarding (and muttering, I suspect).

Protoypes
We talked about prototypes in JavaScript, and I recalled this from the dingy corner of my mind. A Codecademy lesson seemed to linger there in the shadows. Prototypes are essentially the perfect Platonic form of a function that exists under the layers of what the programmer is manipulating. The attributes and methods can be accessed under the "skin" of the machine.

ES2015
This is the latest version of the JavaScript language. It has gone through a handful of name changes, but it seems like the consensus now is to update it every year with that year in the name. We then talked about Babel which transpiles our fancy new shiny JavaScript into the grimy old JavaScript that the browsers are used to dealing with (that JavaScript is called ES5...yeah, it gets strange.).

In the ES2015 newness we discussed a few nuggets that we could use quickly. The "fat arrow" (their words, not mine) let "this" be "this" when inside of something like a React component's "componentWillMount" method. We were already using the "fat arrow" (at least I was!) to be able to use "this" as we expected in React. We also learned the new keywords "let" and "const" which have been very useful. "Let" is to become the new "var" and will not be affected by hoisting in the same way that "var" was. "Const" is a way to declare constants (think gravity and pi) that will be initialized then left alone to be used throughout a program without fear of accidentally mutating the value. I used this in a tax-rate homework assignment because the tax rate was not a changing variable.

Node.js
JavaScript and the browser go hand-in-hand, for without the browser, JavaScript is wont to thrive.

That is all gone now. The good people who figured out the node.js way of doing things have made it possible to use JavaScript in different ways, especially on the server-side of programming. This system is said to make security and especially speed much better. I have limited experience with it so far, but I did attend a meetup at the Capital Factory for the Bleeding Edge Web where many interesting notes were taken by me about this node.js system. More to come about this as I learn more.

Google Maps API
Aaron went over how to find the Google Maps API information and how to build a basic map with some markers and messages. I used this to build a map of the city where my family lives complete with markers and messages custom-made about our city and house. The kids loved it, and I had fun making it!

Big O Notation
As with most things in computer science, I dig learning how the computers work. Aaron mentioned how nested "for" loops related to the estimated time it takes to complete them and how mathematicians/computer scientists use "Big O Notation." On my own I went
here and did further study to learn more about the way algorithms relate to the estimated length of time needed to complete them. Supremely interesting to me. Logarithms and binary searches follow closely in this area.

TED talks
As a former co-worker of
Frank Troyka, the venerated teacher and leader of young people, and a lifelong learner, I have been watching TED talks for many years. The talk with Simon Sinek about "How great leaders inspire action" is definitely a good one. The golden circle principle is well-explained and instantly makes sense with his illustrations and examples. TL;DR know WHY you are doing what you are doing.

Angular
This is a MVC framework created by people working at Google. We have used Backbone, which is a MV* framework. We have used React, which is mostly the V of the previous examples. Angular is huge and does a lot of things. Aaron walked us through some models, controllers, and modules, and we discussed two-way data-binding. I had done a very small "to-do list" tutorial before, so some of this was not foreign to me. However, it is a good deal different than the ways that we have approached similar problems. I feel confident that I could pick it up, if needed. I do find it odd that Google doesn't actually use this in production (at least, to my knowledge).

User Stories
We definitely talked about this during our hackathon several weeks back as well as our group project. It is useful to bring up again since this is the WHY of programming. We need to know what it is we are needing to solve and how the program is being used, etc., etc. I feel like our final project preparation was most difficult for me because of getting the user stories on paper and articulating certain issues that needed attention. But, like with most things, once I got the words on the page and started rearranging them, the user stories became much more clear.

Et cetera
Several other great things happened in these weeks since I last wrote in this space. I figured out how to pass data and methods up and down through React components. It is not 100% in my brain yet, but I am inching ever closer.

I also attended an "Open House" held by our campus. I met several people who are possibly entering the next The Iron Yard-Austin cohort in February. A really cool benefit was meeting the new campus director of The Iron Yard-Dallas, Caitlin, and getting to talk to her for a good long while about life, the universe, and everything. She is good people, and I am really excited for the Dallas students coming soon. I know that I will certainly be on-deck whenever needed to help the next generation of The Iron Yard students get their feet wet!

Speaking of, we also had a ton of rain last week and massive flooding in ATX. I drove to Dallas and it took about seven hours (that is 2x longer than usual). Halloween apparently happened...that escalated quickly. We talked to Travis about cover letters and résumés. I made my app for the final project pretty much do what I wanted (after much consternation and rending of garments, followed by proclamations of joy and triumph). Lastly, I learned that Twitter was launched here in Austin at SXSW in 2007.

Wow! What a busy time! More to come soon about my final project. Stay tuned...





On Group Work

or Avoiding Merge Conflicts in Version-control

Week 8 at The Iron Yard found our Front-End Engineering class heading into a group project. No big deal, we should all know how to work together. I mean, we are all adults and have gotten through high school and other jobs and stuff. Oh, yeah...there are 16 people in our class. This could quickly have been a formidable challenge unless we were careful about how to divide the planning and workload.


from the blog of The Iron Yard

Our user story was from a teacher named Gill Bates (hmmm...seems like a familiar name). Gill needed an application that can create quizzes and then have the students take them. We were given some core functionality that should be present, including a set of needed analytics. Our instructor Aaron helped us break down things into a usable workload using Trello. After one student created the main GitHub repository, we then spent the rest of the day in pair programming.

I was paired up with Mike D. (not the same as the Beastie Boys fella), and we decided to tackle the Class Analytics that would allow a teacher to select a quiz and then see the class average for each question. The class was using a Parse account that Aaron set up to allow us to access data on the server. Mike set up some dummy data while we took turns getting our basic React component set up. The largest hurdle for us to overcome was the querying of three of our four Parse Objects. We used inner queries and some other logic to gain access to our needed data and manipulate it. Working to understand the relations between the data models definitely took some time, but we ended up being able to talk through our process and get the code written.

Planning

We did not spend enough time here. We should have mapped out all functionality first. We discussed the code standards, but we should have been even more specific. Some people were not indenting the sass nesting very well which made it very difficult for others to use later on. Other people would use inconsistent spacing between different code blocks. I now have a better understanding of technical debt, alas.

Style

We discussed zero things about the layout and style of the site except to base it on the "get skeleton" CSS layout. When we got into day two of the group project, we finally had a group discussion about which colors to include, but little to no discussion about how to use the colors (which color is the background?, which is the button color?, et cetera). At this point several people had split up and started working independently of each other on styling each component. Since we did not have a definitive style guide established, it became noticeable very quickly that we needed to rethink this.

Thursday afternoon we hosted the design class as they reviewed our design. As we prepared for the review, front-end volunteers were scarce to be the person to present our project to the design class. I was barely paying attention, figuring that someone with less public-speaking experience would really need the practice of getting up in front of seven people we all know to talk for a few minutes. Guess what, they picked me and told me as I was gazing into my Sublime Text editor. Sounds good. I did not really agree with our color palette (at least the way we were implementing it), and knew that the styling and UI/UX of some of the site was a big issue. This helped me guide the designers through our site to seek out their help on our problem spots. They had some great insights to help us reconfigure our color scheme and our general approach to several aspects of the layout. Afterwards they provided some style tiles that we used to shore up some design issues.

Git

We had a surprisingly low number of git issues. I really think that our class is doing a great job with using git and GitHub for version control. We ended up with 829 commits on 53 branches. The 192 pull requests all went pretty well with most people putting up code that really was ready to merge into the master branch.


branches
A small snippet of how many branches our group had going at once.

Teamwork

This project put teamwork into focus for me. We didn't really assign a leader other than the de facto teacher and teaching assistant. Due to this, it was a bit of an issue with getting the group to fall in line with guidelines and communication standards. I have spent my career as a music educator getting young people not only to achieve greatness but to do that as a unit. I am used to gauging the team sprit and creating a positive culture and vibe. I certainly tried to apply that to this project, too. Leadership in a team or organization revolves around influence. I do not take for granted the years of training and experience I have had as a leader. Though many of my classmates may not have been blessed to work on great teams with great leaders in the past, a lot of them will get better at this through projects like ours and future work. No one was extremely difficult to work alongside, but it was obvious that some people were not used to working with others. They have a great opportunity for improvement, and people with experience as leaders can help move them along more quickly.

I think our project ended up fairly well-styled. All aspects of the desired functions were implemented very well. The user should be satisfied. Aaron is going to use our project with the next cohort to make quizzes and have the class take them. We will get real-world feedback on our project in two or three months!

Check out the live site and poke around for a while -
tiy-austin-front-end-engineering.github.io/

Ciao!

Hackathon Retrospective

Real-world kinda stuff right here

Our introduction to working in teams was rooted in Agile. On Wednesday, our guest speaker to introduce our students to the concept of Waterfall versus Agile/Scrum was Sabina Winters from here in Austin, TX. We learned all about user stories and sprints and always talking to your scrum master and how Waterfall doesn't make sense for software development. Scrum is a funny word, but it makes a lot of sense.

Then on Thursday we were divided into groups, told to head to lunch and come back to campus to pitch the staff on a project of our choice. Most groups were like mine: two front-end developers, a back-end developer, and a designer. My group had Ryan Y in the back, Mory F. and me in the front, and Liz S. in the design seat. Our front-end requirements mandated that we use the Backbone.js library, but only the models, collections, and a router, though we also needed to use Views for our particular functionality.

After a delicious lunch at Freebirds World Burrito on South Congress in ATX (
WHAT! You have NEVER been to FREEBIRDS?!!?!), we had settled on two different ideas that we all thought had enough features to cover our bases and still push us to make something cool and (hopefully) useful. The main idea was to design a web application that could help Austinites reserve a parking spot for their favorite local restaurants. Austin has some terrific food, and parking can be fairly difficult. This is a useful idea that would be used by many.



Turns out, git and GitHub can be a challenge. We had different repositories for back-end (Ryan all by his lonely) and front-end + design. This meant that Liz, Mory, and I had to stay on top of "who is doing what" for much of our time together. Thankfully, our campus director
Travis Swicegood literally wrote two books about using GitHub, so we leaned mightily on his knowledge and experience on Friday when getting started on repository work. (He also helped me set up some bash-it themes on my machine which always show me the current git repository and its status!)

A portion of the challenge of working with two front-end developers was how to divvy up the work between us. I started to work on our main.js file while Mory started getting the models and collections put together. As we began to focus on one file at a time, we found it much easier to do
pair programming, with one of us helping talk the other one through coding. This has many benefits, but we found that the major ones were fewer errors (since someone was helping catch misspelled words and punctuation) and we could push our files to GitHub on one computer at a time. An added, non-obvious benefit was watching and learning from someone else's workflow, especially the myriad keyboard shortcuts.

We could not quite cross the finish line with the features that we expected to "ship," but we learned a lot and incorporated a good deal of functionality in populating our webpage with data from the custom-built API (thanks, Ryan!). The design that Liz created and built worked like a charm. Mory and I had Liz imbed templates in the HTML, which means that she alone could work on the HTML and Sass files to her liking. That left us front-end fellas to determine how to look into the server and put that data on the webpage. We used our JavaScript, jQuery, AJAX, and Backbone skills to dig around and eventually we learned enough about Views in Backbone to make things happen.



I am exhausted, and it was a tough push to get to the finish line. However, it was worth it. Today we started using React.js (built by Facebook), and it is making a TON of sense to me. This is certainly a combination of Aaron Larner's brilliant teaching (I have worked with a lot of those...I know one when I see one!) and a natural outgrowth of working so intimately with Backbone for the last seven days.

Things are looking good for the future as these concepts being hammered into me are starting to turn into a sensical set of instructions to make these computers do what is expected. Being in Austin is GREAT...except my family is back in Dallas, where I will be looking for a job not long from now. Off to finish more React.js learning....
(do we ever finish learning, though???)

Backbone Basics

Backbone makes it easier

Our front end engineering class has brought us to the point where we know enough book information to make a desirable number of features on a website. We have learned a good deal of HTML and CSS for basic, good-looking website content. To increase the power and ease of using CSS, we learned Sass which is a pre-compiler for CSS. All of this knowledge brings us to the point where we can talk to designers and get a basic page built fairly well.

From near the beginning, we learned vanilla JavaScript in node in the terminal (or in Sublime Text, if you are fancy). Next we learned how to link the HTML/CSS into the JavaScript to provide functionality to our websites. We then learned some jQuery, a JavaScript library, to quickly target areas of a webpage for interaction. Just as soon as we were getting comfortable with mixing JavaScript and jQuery we discovered that AJAX lets us deal with a server to store information in a place other than the client's computer. This allows us to work arm-in-arm with our back-end brethren and opens us up to the world of Backbone.js.



Backbone is a library that is written in JavaScript and also incorporates jQuery and Underscore. This particular library uses the MVC architectural pattern that stands for Model-View-Controller, some of the main ingredients that make this approach attractive to many. I certainly have a freshman-level view of these concepts, but I can already see the appeal of having the page updated in a dynamic way. The main basic idea of the Backbone (or another MVC framework) approach is to have the internal use of data separated from the user's computer. Backbone code will be set up to listen for changes to the website and then will interact with the server behind the scenes to initiate and carry out those changes.

While somewhat easy to explain in those terms, the code is already sometimes becoming rather large. When the lines of code begin to pile up, it is best to step back and remember the bigger picture. We will set up a
model that will exist between the user's page and the server. This model will be our "single source of truth," as our instructor Aaron likes to say. When a change is made, the model is consulted and then it interacts with the server behind the scenes to make changes. Backbone is also smart enough to carry out changes that are needed. In other words, it will not refresh your entire profile on your social media site if you only change your picture. Backbone will just change your picture and be done.

Without a doubt, there is a long road ahead to grasp all of these concepts. Thankfully we have our
hackathon this weekend where we pair up with the design and back-end cohorts to create and implement a project of our choosing. This will be a great way to learn how to work with these other two elements of web development to realize a project. I am really excited to work with these folks!

To infinity and beyond,
Mike

Image Gallery coming

Building a gallery for images posted from users

We have spent the week learning how to simplify JavaScript down into jQuery (although, that is an oversimplification itself, in some ways). Then we learned how to connect to a server using AJAX, pushing information to the server and then learning how to retrieve it. When you put that information alongside the small projects we did all week like creating a login page and making a todo list, then creating an instagram clone (albeit a smaller scale) is a logical outgrowth of that.

So, that is my goal for today and this weekend. If you need me, then I will be under the hood of Sublime Text reading some Input Mono and muttering to myself incomprehensibly.

Now time to leave

And head back home to

Meetup Notes - Designing a web app

Design Meetup @ The Iron Yard-Austin

I learned some
Photoshop tonight! I have embarked on a quest multiple times over the years to learn Illustrator and Photoshop, but it always ended with me not figuring out how to select or delete or modify what I just created. These are such complicated programs!



Our guide on this journey to learn basic Photoshop was Abby Larner, from The Iron Yard-Austin design staff. She was extremely comfortable with the program, having used it for over a decade, and it was a cool project to create. We were going to make a Facebook-like page for dogs called "Bark." This page included such things as "wags" instead of "likes" and dogs named Fuzz Aldrin and Bill Furray.

We started with a
wireframe and needed to learn the use of some basic tools in Photoshop to create items and manipulate them. Honest truth, I was a slow learner here. Some of the tools' layouts seem counter-intuitive to me, even as a longtime Mac user (or maybe in spite of that). I definitely made plenty of notes in my fancy Baron Fig notebook (with a dot grid) about keyboard shortcuts and the order of a needed workflow. This will prove valuable later when I have gotten hungry or distracted by some other aspect of life, and necessarily forgotten how to get anything done in PS.

On a practical note, using Photoshop will likely prove to be extremely useful to me as a developer. Designers will make a mock-up of a website and provide a .psd file (the proprietary format used by Adobe for a Photoshop file). This file will have the exact dimensions and colors needed to build a website from that design idea, which will allow me to create a pixel perfect recreation for the client (and designer!).

So, here's to many more encounters with this behemoth program. I have a feeling that, like with most deeper computer technology things, it will prove to be a long road to get the most out of it. Perhaps I will even get a high-quality camera and learn to
really use the program for it's original intent!


TIY - Day 15

This is it...don't get scared now...

We have driven deeper into this world of JavaScript and jQuery. Today we talked about review from last night's login page homework. I did not have time to get it fully implemented because I went to a meetup and watched some blazing React.js happening. I mostly understood it, but today Aaron showed us some things that made a lot more sense.



We learned how to interact with a server using AJAX. Not the cleaner bleachy stuff, heavens no! Of course I mean Asynchronous Javascript And Xml. Everyone knows that!



This allows us to give information to the server, remove information, or update information. (A slew of other things are also available, but this is plenty for now.) Now, you might be saying, "Hold on, Tex. What is a server? You talking about my waiter at Chili's?"

Great question! Most people have heard about things that are stored in the "cloud" and maybe they don't fully understand what that means. A google search of the phrase "the cloud" returned "About 47,500,000 results." SOMEONE is talking about it on the interwebs! The cloud is a great little marketing phrase for what used to be called servers. These are computers whose job consists of connecting other computers together and storing data. When you backup your iPhone to "the cloud," it is really connecting to a remote computer somewhere that is holding a copy of your iPhone backup. To be fair, these days we are using a lot of wireless technology, so it does seem as if things are magically happening through thin air. Perhaps that is why the phrase has caught on.

Anyhow, as we learned AJAX a bit today, it becomes plain to see how useful it is. I can finally get a better picture of how our job as front-end developers is to build out a website
and understand the ways in which it will interact with a server a.k.a. "the cloud." Today we built a little chat utility in the browser using jQuery and AJAX that could store information in an object on the server and then retrieve that information in order to provide a running list of messages in a chat room.

We have some fairly complex projects coming up, so things are about to pick up quite a bit, I feel. Time to buckle down and continue the onslaught, come what may.

What is 'this'?

Week 4 - Day 14

JS 'this'

Ok, things are about to get confusing. If you are not thinking clearly then go skip this and go read the facebooks or something. Maybe go take a walk.

Still here?
Well, let's talk about 'this'...



Just kidding. This is awesome. The easiest way to put this...erm, what I am trying to say is...the best way to get this down on paper...blurgggg... Using this word seems nearly impossible!

In JavaScript we are often dealing with a small snippet of code that does a task. It is called a function. Inside that function we might be targeting a specific item that triggered an event. A shorthand way of talking about some information that is passed in to the function is to use the
this keyword. It enables the programmer to talk about a generic piece of information without knowing exactly what it is ahead of time.

Specifically,
this refers to the current DOM element, at least in the way that we have been using it in class. It is also useful when creating new objects with a constructor. I have not used it a ton just yet (only a couple of times), so I have yet to build up a lexicon of knowledge to disseminate to the masses about this.

Also, here is a .gif. Enjoy!



If you want to learn more about
this, then go to MDN or just !google search it on DuckDuckGo.

The Iron Yard - Day 13

Week 4 - Day 13

JS + HTML = :]

Our homework over the weekend was to construct a to-do list using vanilla JavaScript i.e. just plain ol' JavaScript with no bonus features or extra doodly-whatsits. My implementation of this works pretty well. I wanted to add a few more features to it, but I had to learn some deeper concepts first.

On Friday
our instructor told us it was his favorite day of the entire span of twelve weeks. We officially learned to connect JavaScript to our HTML to produce a page like we are used to seeing in the wild. Remember, constant reader, the JavaScript is what enables actions to happen on the page inside of your browser. For instance, if you look at my very plain to-do list, you will notice that clicking the button next to the text input area will make that text appear below in a list format. While this may seem like an easy task, it does involve many steps.

First, we target the specific areas on the webpage that need action. On my list, those specific areas are the input text field, the clickable button and the "list" section below that.

Second, we create functions that tell us what action we wish to happen. For instance, when I click the button, the text from the input text area should become visible in the list section. At this point we should have thought about what areas are needed and what we need to happen with those areas.

Lastly, we add what JavaScript calls "event listeners" to be the messenger between our targeted areas and the desired functions. In my example of the list, I have JavaScript "listening" for a 'click' from the user on the button next to the input text area. When that button is clicked, the text is added to an array behind the scenes, the list section at the bottom is erased and redrawn with the updated list. All of this happens so fast that we cannot see it, but for every item added to the list, the entire list is erased and started over with all values. I am told that this will be useful later!

My reset button on the list example works in a similar fashion. It is "listening" for a 'click' to happen and then it interacts with the list values by resetting them all back to empty or zero and then redrawing the list section to reflect that.

In honor of our teacher
Aaron, enjoy some nutella...


The Iron Yard - Week 3

Week 3 and Other Tidbits

In my quest to switch careers, a coding bootcamp seemed like a good fit. Through a mutual friend, I talked to a former student from The Iron Yard that attended the original campus in Greenville, South Carolina. He had gotten a job in development in Dallas at a smaller shop doing some cool work. The job market for coding in Dallas has plenty of open positions. After being a band director for twelve years, I was right at the point of getting ready for a new direction. My aforementioned contact said that the thing he would have done more before bootcamp was studying JavaScript.

JS-woody-buzz


Thankfully, I followed his directions. I went through the
Codecademy course on HTML/CSS and JavaScript two times each, the second time around carefully hand-writing nearly all of the code. Hey, I learn best by writing, and it keeps me focused, be nice. (You probably do, too.) I also got the book Eloquent Javascript by Marijn Haverbeke and read (and worked) through the first three chapters three times. You might think I am a JavaScript champion now. I would say that I was simply practicing and getting some mental and physical muscle memory built up. I knew that JavaScript has some weird idiosyncrasies that make it identically a mystery and a brilliant tool. My goal is to understand those and make them work in my favor.

A fun example: like most programming languages, JavaScript has certain base "types" where it stores information. This could be a number like 9 or a boolean like true or a string like "The Iron Yard" or an array like [1,2,3] or an object like {a:1, b:2, c:3}. Got it?
No, you don't.
An array is actually a type of "Object." Gotcha.
Unless you are working in the browser, then it could be an "array-like object."
HUH?
Exactly. That is JavaScript. It is weird and funky and a lot of fun. (Hey, I used Turbo Pascal and C++ in high school... I put in my time with the strict languages!)

This coding bootcamp experience has been daunting and scary at times. Other times I feel like a rock star when the code works and my tests come back with green check marks! YES!! My classmates have been cool to be around. Everyone seems interested in learning their stuff and getting work done. Staff is fantastic. The campus is in Austin...a wonderful place with great food and great people. I miss my family SO MUCH, but it will be worth it when I get a wonderful job back in Dallas with a great team shipping things that make the world a better place.

Something that has surprised me is that I was terrible at my first attempt at coding bootstrap. I haven't really finished my assignment from a week ago...it looks like I really need to start it completely over and rethink my approach to the grid system of the masses. Not everyone gets ALL of it the first time!

I definitely expected a challenge, and it has been delivered in nearly every assignment. Even when I feel like I have a decent level of skill, I know there is a long road ahead. I am always keeping in mind I am still near the left of the flow chart from the mind of
Mihály Csíkszentmihályi (pronounced "chick-sent-me-high"). As a musician, I achieved flow by getting my skills and challenges to extremely high levels. I feel like after about 15 years and thousands of hours of drumming that I was pretty accomplished. Hopefully I can get to flow sooner in coding!



To any future students, please hang in there and keep a positive attitude. Ask questions. A lot of them. The days I have been most frustrated were the days that I felt most isolated. Ask your staff, ask some mentors, definitely ask fellow students. No one can do this alone. I highly suggest doing some exercise to keep your body and mind active, as well. Lastly, I am a fan of writing things down (did I mention that?). I filled our moleskine cahier notebook in the first five class days. If it helps you learn, then GO FOR IT!

The Iron Yard - Day 08

Tic-Tac-Toe

In our quest to learn about loops of all kinds, the task at hand is to create a game of tic-tac-toe (also, called "Noughts and Crosses" across the pond) built in JavaScript to run in node on the command line.

Noughts and Crosses


There are some complications to this problem that are not obvious at first. We are making it a two-player game (except for nightmare mode is building an AI to play against). We start off asking for the players' names, and setting the current player to player1. Then the player must enter the coordinates of their move in the format "x y" (yes, with the space). The move is stored in an array that holds three arrays which I am calling gameBoard.

All of that is fairly simple (yet time-consuming) except we need the array to hold the numbers of the coordinate, and the way it was entered is a string. Thankfully, in JavaScript there is a method called
.split that allows a string to be split by a separator, which I defined as " ". This leaves us with a string of two numbers. The trick now is to use parseInt to get the numbers pulled out of the string and put into the array as a numeric value. This was a bit of a logical challenge simply because I had not really used all of these little processes before. However, like my old days as a music educator, I just have to tell myself (instead of the students) that the best way to learn is by doing it!

For the next part, I don't
love the way I constructed it yet. We must determine if the entered information was, in fact, the correct format, an acceptable number (1, 2, or 3), and that no one has taken that location. My solution here is incomplete and inelegant. I will continue to work through it!

I did manage to make the game board print with the correct player's token in the correct spot. That was a huge moment! Also, I have made it successfully switch players and I have gotten as far as declaring a winner if they get a row of their token (still have column, diagonal, and cat left!).

All in all this has been a good week, but I still have to touch up some of the responsive site stuff from earlier this week. I will do that today. We have a campus-wide huddle at 10:00am and
Iron Pints at 3:30pm. Also, I have to take my car in to double-check that the light that came on will be ok. Heading back to BIG D tonight!

Oh... and my oldest child turns thirteen on Sunday. We got old all of a sudden!

The Iron Yard - Day 07

The Iron Yard - Day 07

We have learned about arrays and objects. We are now aware of the matrix...

matrix_screen_saver_by_icyalaska

An array is a data structure that lists information in what we can think of as an ordered list. This might be most useful when needing a list of items such as a cash register needing to access prices or perhaps an inventory. Square brackets are used to start off an array, and all data types can be stored here.

An empty array named
groceries looks like this:
var groceries = [];

An
object is a data structure that functions more like a large bag that holds pieces of information in any order. Objects are central to the more advanced abilities of modern programming languages. The information stored in an object has a label to go with the value. Curly braces indicate the beginning and end of an object, and all data types can be stored here, as well.

An empty object named
kitchen looks like this:
var kitchen = {};

Arrays
We need to insert data into our array, so we will use the method .push() to insert data into the front of the structure. (You can also add data at the end or the middle, as needed.)
groceries.push('milk');
groceries.push('eggs');
groceries.push('bacon');

So our array now looks like this:
['milk', 'eggs', 'bacon']

These values inside the array can be retrieved and used by referring to label of the
position of the value. For instance, milk is at position 0, eggs at position 1, bacon at position 2. (Due to largely historical reasons, many times computer scientists will begin counting with zero.)

If we need to access an element of the array and reassign a new value to the spot that holds milk, that would look like this (pronounced "groceries sub zero):
groceries[0] = 'whole milk';

Objects
Unlike an array, an object is not ordered, so we cannot
push things to the object. Instead we have to access keys that behave as labels for the objects inside the array. If the keys do not already exist, then they will be created as we give them a value. For example:
kitchen.flour = '2lb';
kitchen.eggs = 1;
kitchen.coffee = true;

The above values don't have just a generic label but have a custom label. If we need to access the values inside an object we can access it much like above. If we want to reassign a new value to an object, then that would be identical to the assignment above.

Objects have two ways to retrieve data from inside: dot notation (usually preferred) or curly braces notation.

A
Matrix is created when we store an array as an element inside an array. If we had three arrays stored inside of an array, then that might look something like this:
var matrix = [
[0, 0, 0],
[0, 0, 0],
[0, 0, 0]
]

This could conceivably lead to some rather complex data structures.

Anyone ready for tic-tac-toe?


The Iron Yard - Day 06

The Iron Yard - Day 06

On Tuesday we dove a little deeper into JavaScript discussing boolean operators, the ternary operator, and conditional statements.



We also discussed several scenarios that JavaScript handles in a quirky way. Type coercion in JS has its own rules that will be wonderful to harness once a developer can fully grasp them.

For instance, let's assign a value to the variable "name" and put it into an important sentence.
var name = "Mike";
var statement = name + " is really cool";
var name = "Bob";

One would think that the output would be "Bob is really cool"... Nope, it is still "Mike is really cool". Confused yet? The logic works like this:

Name holds the value "Mike"
Statement holds the value "Mike is really cool"
Name is given a new value of "Bob" which replaces the original of "Mike"
Statement is asked to show the value it contains, which is still "Mike" - we did not put a new value into Statement

Our homework was to use plain JavaScript to create a command line quiz in either normal mode, hard mode, or nightmare mode. We were to include 15 items that covered various HTML, CSS, and JS topics and then tell the user their number correct and percentage. I finished that and made some adjustments to also tell the user which topics they did best in and I made it display the correct answer if the user gets the question wrong. I also added a timer to tell the length of the test. As a bonus, I made a "100" display in ASCII characters if they get every question correct.

The nightmare mode (which I did not employ) asked the developer to make the quiz adaptive based on the success of the answered questions. I could see how this is possible, but my code would have been MUCH longer to make it work.

Now, I am
still working on my HTML forms homework from Monday. I will finish this TODAY!!



The Iron Yard - Day 05 part 2

The Iron Yard - Day 05 part 2

Solidly into week 2 now and things got real. Our JavaScript assignment was pretty straightforward, and I had no issue getting that done. We had to make a table in HTML with some answers to JavaScript questions that Aaron provided to us. My version of the assignment ended up looking very nice. I learned some nifty things about using tables in HTML. Thankfully I have studied a decent amount of JavaScript to prepare for the course. It does tend to make sense to me overall.

Our other assignment has me twisted in knots. It deals with using forms in HTML, just like the little buttons a user will push or the checkboxes you see on a website. I have the page looking
mostly right except a few elements just will not go into the correct place. I could only get about 60% of the way through the homework before I had to sleep. Hopefully this is a situation where things will just click when I approach it again in a bit.

Apparently, radio buttons and their text are nonsense to my brain on a Monday evening. I will have to work overtime to be able to get those up and running!

Breaks are helpful, I am finding. Occasionally you just have to get up and take a walk outside for a few minutes. In fact, your brain is still turning that problem round and round to work on it. Many times I have sat back down and busted out some serious problem-solving skills. Waking up and coding is just as beneficial.

Time to head to Day-06! Woot!

The Iron Yard - Week 1

The Iron Yard - Week 1

Week 1 is finished! We made it through! We have sixteen Front-Enders in our class, and we have covered a lot of ground during the first week. We have learned how to use HTML, CSS, Sass, git, and the command line. We have made several layouts and reproduced two websites on our own. Very enlightening!

front-end-engineering-icon

Although I am an optimist and have a good outlook on things most days, there were several "throw my hands up in the air" moments this past week. Why doesn't padding work the correct way on a parent element in CSS?!! However, by and large I can see the bigger picture of really GETTING the material.

The hardest thing has been being in Austin away from my wife and four kids back in Dallas. The focused work and study time has been incredible and necessary, but the hugs and experiences I am missing cannot be made up later. Thankfully, Dallas is not too far away, so I was able to head home for the weekend. I have to keep my eye on the prize and get my skills to the level that a company will want to hire me to be a part of their team. As a former band director, I have a TON of soft skills ranging from leadership down to organization to communication to management (not the same as leadership!).

Now...let's see what Week 2 has in store. I hear that we dig into JavaScript, which is what I have mostly studied leading up to this point!

The Iron Yard - Day 05

Day 05 - SASS part2

Something learned very early in development or programming is the beautiful phrase "Don't Repeat Yourself" - usually referred to as DRY. Learning about Sass at The Iron Yard, on my own a bit, and at a local Austin meet-up was a great way to work it in to my homework project. The group ATXSass had the great speakers Abby Larner and Una Kravets. This was a fun presentation about the basics of the tool. Also, having gone to this meetup in ATX and several meetups in the my hometown of Dallas (woot!), I can easily say that the tech scene thrives on getting together. There is something magical about finally meeting the people that dance across your Twitter account as pixels... They are really real people, turns out!

Some more thoughts about Sass, the beneficial CSS pre-compiler follow the nice sassy picture.



Mixins
This handy-dandy feature behaves like a variable but lets you put in more lines of code. If you are familiar with a formal programming language like C++ or JavaScript, then you might consider this to act like a function.

At the top of your code (or really anywhere
before you need it) add a mixin by including this code:
@ mixin link() {
background-color: pink;
color: white;
}

This means that we want to use the visual configuration of white text on a pink background - and we are likely going to use it more than once in the body of the code. Perhaps this is useful if a person is dealing with several sections that will have the same formatting.

When the mixin is needed in the code (after it has been declared!), then just use this to include it:
@include link();


Now...a great reason I saw to use this in code. It is becoming accepted to use the measurement "em" when dealing with font size. This is based on the current font size or approximately 16 pixels. (Pixels are points of light on the screen) - If you have a picture that is 800x600, then you are dealing with 800 pixels horizontally and 600 pixels vertically). Using a "em"s is smart when considering that the end user will likely increase the size of the content (think smartphone or tablet). This means that the font size will scale appropriately when the entire page is "zoomed in".

Here is a snippet of code that will allow us to insert font sizes as the "em" measurement, but also provide a measurement in pixels.
@mixin font($em) {
font-size: ($em*16) + px;
font-size: ($em) + em;
}


(
Note: not all browsers on all devices support all of the things written, so it is a good idea to provide measures like this to shore up your code to be backwards-compatible to older browsers).

The perceptive student will note the $em is a variable. Mixins can include variables, which makes this a very powerful tool! This can be called from within the code like this:
footer {
color: blue;
font-weight: bold;
@include font(4);
}


There is SO MUCH MORE to learning Sass, but this is a good primer for getting started. I know that I am learning a ton more about how to use it to shorten my code and to keep it DRY!

The Iron Yard - Day 04

Day 04 - SASS


image courtesy of sass-lang.com


Whoa, baby, this stuff is cool. Syntactically Awesome Style Sheets or, SASS, makes writing CSS a much easier process. There are two versions. Hamburger A is Sass, Hamburger B is SCSS.

We learned about the SCSS flavor in class today at
The Iron Yard. Sass lets a developer write complex CSS in a simplified way using various patterns.

Nesting
This makes the HTML and CSS look more similar in structure. The code snippet below has a nav tag (which functions as a div container, just semantically different) which contains an anchor tag. The SCSS lets a developer nest a CSS property inside of other ones. SCSS will automatically compile to stock CSS in another file. As a visual person, this is extremely helpful because I can now easily see which tags are inside of others as opposed to searching through hundreds of CSS tags.

This is generated:
nav {
background-color: #fff;
padding: 0.5em 0;

a {
margin: 0 1em;
color: #565D64;
}
}

Which puts this into the stock CSS file:
nav {
background-color: #fff;
padding: 0.5em 0; }
nav a {
margin: 0 1em;
color: #565D64; }

And you might be thinking, "Big whoop. That is just as easy to write in CSS!" Well, you might be right, pardner, but as you mentally extend this to a larger framework of a site, it becomes easy to imagine the usefulness of this here technique.

Variables
SCSS allows defined variables to be used throughout the code. I learned about some scenarios today which made this seem like the greatest thing since the wristwatch. For example...

Situation
You are a designer (or an indy developer) dealing with three different main colors on the site you are building. You apply the variable method to your colors like so:
$primaryColor: #bada55;

And you apply it to code like this:
a {
color: red;
background-color: pink;
}

You are building your site and all is fine until one afternoon your client says that she really wants a
deeper shade of green. No sweat if you used the $primaryColor variable. Just go switch the variable at the top of the file and all of the colors switch throughout the layout.

Thankfully, there was also a meetup for ATXSass the very same day that I learned about Sass. What a break! I headed downtown to the
Capital Factory and learned more about Sass from Abby Larner and Una Kravets. More to come about Sass, so stay tuned.


The Iron Yard - Day 03

Day 03

2015-08-26 11.58.21

Today we had engaging lecture and examples over the specificity of CSS selectors. I definitely do not fully have it down, but it is starting to form in my brain matter.

HyperText Markup Language (a.k.a. HTML) is content. It contains everything that you see on the page that is
stuff. The containers that hold text, pictures, and links can be made to look prettier by adding Cascading Style Sheets (henceforth dubbed CSS).

CSS makes use of
selectors to apply a certain style to the content in the HTML page. In best practice, the HTML and CSS code are found in two (or more!) different files which are linked together at the top of each HTML page.

Color, font-size, height, width, and many other values can be added or adjusted to the content of the page using CSS. If you have seen a website, then you have definitely seen this in action. Without the CSS, the page looks like an outline on black text on a white background

CSS Selectors are fun!

Tag selectors are HTML tags (such as <
header>, < body>, <img>, <a>, etc.) that we target in order to style.

Tag selector example in CSS

body {
text-align: center;
font-family: "Roboto Mono", sans serif;
}

Class selectors are custom names that a developer can create to help modify the appearance and behavior or certain attributes.
In the HTML document they take the form <
HTML_element class="class-name">.
In the CSS file they are preceded with a period like so
.class-name {...}.

Class selector example in CSS

.class-name {
display: inline;
margin: 0 auto;
}

ID selectors are unique names that will only apply to a single element on the page (or a set of things, depending on how implemented). For best practice they can only be used one time per HTML document.

ID selector example in CSS

#batman {
background-color: black;
color: black;
}

That was the easy stuff. The fun begins when we try to determine what happens when the selectors are combined. Which one takes precedence? Will my text be blue or red?

Lastly, a
style tag included in the HTML side of things can override any of the CSS selectors from above. It is generally considered a party foul to use style in that context. Styling can be done "inline" in HTML, but this is an activity perfectly suited to CSS.

FUN stuff!!

The Iron Yard - Day 02

Day 02 of The Iron Yard has happened. I lived through it.

After learning several tidbits about CSS tricks and how to use floats and overflow, we had a daunting assignment. We were tasked to recreate the home page of
Wordpress.com in various stages.

Honest Abe, I was a bit stunned at such a complex project.

Copying others is useful to get deeper down into the "how" of any skill. For instance, in my undergraduate music education days, my percussion professor, the illustrious
Dr. Brian West, would require drumset students to listen to a song of our choosing and then transcribe the exact drumset part. We also had to perform it in front of our peers or in front of a panel of percussion teachers. This was time-consuming and difficult…and I loved it. I officially transcribed Max Roach, Art Blakey, and Billy Martin, all of which led me to many others to transcribe on my own.

Other things I learned today:
  • How to use "em" versus "px" (though "rem" will be useful soon)
  • Make boxes "float" left and right like a magnet
  • More study of the CSS Box Model
  • "box-sizing: border-box" (behavior which "turns out" is from very old IE!)
  • Using "git" in the shell to upload projects to GitHub
  • Installing new packages in Sublime Text

I definitely did
not finish the homework by 10:00 PM as expected. I looked up from feverishly typing and hitting - then -R, realized it was 10:00PM and 30 seconds, and then sent my work to GitHub lickety split. Alas, by the time I submitted my GItHub link to our instructor, it was definitely 10:01 PM (at least on my laptop).

Nonetheless, I continued to work on the layouts, and finished what was expected about 12:15 AM. It has been submitted. I can sleep a little.

There were still two spacing issues in my layout where text was out of alignment for about 5px. Annoying, but I will figure it out.

Oh, we also found out that
our instructor likes nutella…perhaps it borders on obsession. Someone left an anonymous gift of a nutella snack-pack for him. Good move!

To Infinity and Beyond!

The Iron Yard - Day 01

Day 01 of coding bootcamp is in the books.

We have seventeen people in our class ranging from checking this out to seasoned developers looking to update their skills or get a better handle on the fundamentals. The story from person to person seems very similar; we are all looking to get into the tech industry and want a career that can be jump-started here at The Iron Yard.

After introductions we got settled in to our classroom in Building K, which is just a little walk from the main Building C. We were promised a fast-paced difficult journey, and they did not disappoint, even on Day 01!

The first material our instructor Aaron covered consisted of command line basics (open, ., /, path, cd, .., ls, ~, mkdir, yo, touch, subl). Then we jumped to HTML and went through the form of the page and the behavior of and
tags. Lastly, CSS basics with a great deal about how to use classes in conjunction with an HTML file. Other goodies: Chrome Inspector (😍) and Digital Color Meter, both very useful tools.

Our assignment was to recreate a page layout using HTML and CSS based on a picture of a layout. At first glance I thought that this was a fairly easy assignment. After spending about
six hours on it, wading through several rookie mistakes, I have a better understanding of the challenges that lie ahead!

[Mike]: Wait… you can put a
inside of a
?? Then, where do I add padding… but I thought that was the margin…

I will learn. We will all learn.

My favorite things I learned on Day 01:
  • The "open" command is useful in the shell (I know it seems obvious!)
  • Digital Color Meter allows me to find any color and replicate it
  • It helps to read all of the directions in the homework… as a former teacher, this should be stock for me!

I did finish
my homework and am excited to see what they cook up for us today!

As they say here at the The Iron Yard… To Infinity and Beyond!