Amy St. John's blog about tech and life

Technology

2010-06-10T05:03:28Z

I’ve spent most of the last week up to my elbows in fixing computers, setting up computers, and general technology. It should be enough to make someone’s head explode. I sometimes think, “What would we do without it?” and yet I am the last generation that can remember what it was like without it. We get so used to habits though I can understand how we get so lazy. The other day I was going to ask a friend to give me his address before I stopped having a printer so I could print out directions from mapquest because how in the world would I find it otherwise and then I thought, “No, you’ll do it the old fashioned way and you’ll deal with it!” as memories of friends giving extensive directions about “turn left on this street, go 5 blocks…” flooded my brain.

I sometimes think about all the things that we take for granted and I start to understand the way people much older than me must feel. I have a brother 10 years younger than me and I’m sure he’ll never know what it’s like to use a pay phone, or write letters to friends. I love technology and it continues to amaze me, but there are things that I think should never change. I’m not comfortable with a world where everyone has a feed straight to their brain like that book Asher read. I want to curl up with the written word and scribble out my thoughts. I think things should enhance our life but not replace it, much like relationships, and with people spending so much time with their “loved ones” (iPhones, laptops, et al) isn’t that all it really is? Another relationship in your life. You don’t give up your whole self to your lover, (at least you shouldn’t), so why should we give our whole selves up to our computers?

I haven’t been without a computer for longer than a couple days since the year 2005, and even then I had a computer at work to turn to; and before that it must have been about 1998. I am a total computer geek but I am looking forward to my first ever vacation, taking place in a foreign country. I have made the decision to not even take my computer. I almost look forward to it, to get back to those glory days of adventures outside and experiencing everything the world dared to show me. I also seem to be of the last generation that had to know how to entertain itself without devices. Now all you hear from the younger ones is, “I’m bored,” unless they have a constant stream of internet, guitar hero, and TV all at once.

I suppose there are no answers, and I suppose I’m somewhat odd. I read books instead of watching TV. I do dishes by hand before I remember there’s a dishwasher. I’d rather walk than drive a car. Maybe my dysfunctional upbringing has something to do with it. Maybe the lack of electricity and luxuries was an advantage in disguise.

But now I ramble. It’s 11pm and I am at an airport waiting to fly all night to the East Coast. Don’t listen to the sleepy woman.

Why working at home is both awesome and horrible

2010-08-26T01:05:08Z

Why working at home is both awesome and horrible - The Oatmeal

This is my life.

Life starts anew

2011-02-27T01:53:57Z

It’s recently become very clear to me that the biggest immediate goal in my life right now is to get hired by a fun tech startup in the city. The search is both exciting and nerve-wrecking, much akin to dating. “Oh my gosh, what if no one wants me?” But like love, I’m sure that when it does fit for both the company and me, it will be glorious.

So many exciting things on the horizon and I’ve got a smile on my face!

You Must Not For One Instant...

2011-04-24T17:37:39Z

You must not for one instant give up the effort to build new lives for yourselves. Creativity means to push open the heavy, groaning doorway to life. This is not an easy struggle. Indeed, it may be the most difficult task in the world, for opening the door to your own life is, in the end, more difficult than opening the doors to the mysteries of the universe.
Daisaku Ikeda

Of All the Words

2011-04-27T04:41:48Z

Of all the words
Of tongue and pen,
The saddest are these—
It might have been.

John Whittier

Failure Teaches Us

2011-05-08T16:14:40Z

Failure teaches us that life is but a draft, a long rehearsal for a show that will never play.
Hipolito, “Amelie”, 2001

Jobs Are Not Big Enough for People

2011-05-13T23:27:05Z

Jobs are not big enough for people. You ask most people who they are, they define themselves by their jobs. I’m a doctor, I’m a radio announcer, I’m a carpenter. If someone asks _me_, I say "I’m Amanda McKenny, and at certain points in time, I do things for a living".
Working by Studs Terkel

Not Failure, but Low Aim is Sin

2011-05-27T16:11:47Z

swissmiss | Not Failure, but Low Aim is Sin.

I always feel better about my life when I have goals that I’m working towards, and when I am dreaming of good things, however unrealistic. Sometimes I start to despair, and sometimes I think of just giving up because it’s never going to happen anyway, but then I think to myself, “Try harder.”

So Avoid Using the Word 'very'

2011-05-31T17:21:08Z

So avoid using the word ‘very’ because it’s lazy. A man is not very tired, he is exhausted. Don’t use very sad, use morose. Language was invented for one reason, boys — to woo women — and, in that endeavor, laziness will not do.
Dead Poets Society (1989)

It Seems to Me Now...

2011-06-07T03:19:51Z

It seems to me now that the plain state of being human is dramatic enough for anyone; you don’t need to be a heroin addict or a performance poet to experience extremity. You just have to love someone.
Nick Hornby

Would You Tell Me Please...

2011-06-29T04:01:00Z

Would you tell me, please, which way I ought to go from here?”
“That depends a good deal on where you want to get to,” said the Cat.
“I don’t much care where—” said Alice.
“Then it doesn’t matter which way you go,” said the Cat.
“—so long as I get SOMEWHERE,” Alice added as an explanation.
“Oh, you’re sure to do that,” said the Cat, “if you only walk long enough.

Alice’s Adventures in Wonderland by Lewis Carroll, Chapter 6

“A good design won't please everyone.”

2011-07-28T01:40:15Z

Consensus is for Losers

This is a great blog entry from Keith Robinson that states many things that I have tried to hammer into the heads of people I have worked with on designs.

“You simply cannot have a strong design if you have to please too many people.”

The funny thing is that there seems to be a consensus (haha) among designers that this is the case, so my question is: why are we still having to fight people on this? Also, even worse than design committees are non-designers thinking they know best, which results in this: How a Web Design Goes Straight to Hell. The latter subject being what I deal with the most. I know we’ve all been there, and I’m probably preaching to the choir, but I sometimes think, “Why do I even bother?” So often I end up in frustration because of watching people argue back and forth about how I should design something, and wondering why they hired me in the first place when they act like they’re the experts and I know nothing. However, I guess I should take Keith’s advice, “Argue with your clients if you feel strongly they’re not doing what is in their best interests.”

RIP Steve Jobs

2011-10-06T05:38:13Z

Here’s to the crazy ones. The misfits. The rebels. The troublemakers. The round pegs in the square holes. The ones who see things differently. They’re not fond of rules. And they have no respect for the status quo. You can quote them, disagree with them, glorify or vilify them. About the only thing you can’t do is ignore them. Because they change things. They push the human race forward. And while some may see them as the crazy ones, we see genius. Because the people who are crazy enough to think they can change the world, are the ones who do.
Apple Inc.

Date a Girl Who Reads

2012-01-01T22:32:45Z

Date a girl who reads. Date a girl who spends her money on books instead of clothes. She has problems with closet space because she has too many books. Date a girl who has a list of books she wants to read, who has had a library card since she was twelve.
A Girl You Should Date via @brainpicker (via bookshelfporn

Geek VS. Nerd

2012-01-05T00:55:16Z

iambeta:

Behind the scenes

2012-03-15T18:20:42Z

It’s been a long time since I’ve updated this site, and the major reason for that is that I’ve been building a completely new one. Since I’ve also been building sites for other people, this hasn’t happened as quickly as I had originally hoped, but I’m still alive and working away behind the scenes.

Stuck between the analog and the digital

2012-03-24T18:52:43Z

One of the things that I value in the workplace is efficiency. At every company I’ve worked for I’ve delighted in discovering and implementing more efficient methods of carrying out tasks. Being that I’m often the most tech savvy person at a lot of the companies I’ve worked for, I’ve strived to help them adopt newer technologies and methods of running more efficiently, whenever I’m in a position to do so. The managing teams are often very enthusiastic about this, sometimes I’m even part of the managing team, but I’ve sometimes found it very hard to get employees to accept and adopt newer technologies and/or newer methods. This serves as a great frustration for me; when I’ve spent a lot of time and effort trying to make things better for other people and they just dismiss it.

Some might say, “Well everyone has a different way of doing things and the methods you institute may not work best for everyone,” and that is true, but many of the technologies I have shown people are an undeniable asset. For example, the person who needs to re-size 100 pictures in Photoshop, in order to upload them somewhere on the internet (which they most likely even know how to do because I taught them), and says that it’ll take forever. I personally just use automation for this task, but many people do not know how to do this. So I provide them with some easy free software that’s sole purpose is to do this very task for them. You just give it the pictures and it spits them back out at the setting you ask for, but then they just end up not using it and either continue to complain that the task will take forever, or they just neglect to do the task at all. This type of example is an issue I’ve run into a lot. I’ve also run into the issue of people flat out not caring about being more efficient with their work, or having easier ways to accomplish tasks. As long as they are getting their paycheck they’re fine with the status quo; they’re fine with tasks being harder than they have to be.

On the other hand I’ve also ran into people who have been too ambitious, when I’ve provided them with tools that make things easy for them; this can also be disastrous. I’m all for people learning new skills and trying to do more, but the key word here is learning and not just assuming that you know how to do something. The example in this case is designing and setting up a CMS or cookie cutter website for someone. You design and set up an entire website and get it running, and then give them the ability to just edit text in the body whenever they need to, or add images to the body, etc. This all works fine for a while, but then they decide they want to do different things; they want to change the design, or start using different fonts etc, but instead of coming to you and asking for you to implement new designs or features, they try to do it themselves, and all of a sudden a professional working website starts looking like a geocities site from the 90’s. Very similar in fact, to what this comic illustrates. Now I’m not just talking about them changing some colors, or something minor, but things like interfering with the information architecture of the site, or copying and pasting cursive fonts from a word document into the text editor so that they’ll have “pretty” text on the site, not realizing that the typeface is not only unreadable, but is not a standard font on everyone’s computer so it may look pretty on their computer, but everyone else can’t even see the font they were trying to display. If you know nothing about making a website, then the internet is a wealth of knowledge with thousands of articles of information on very basic principles of design and building websites that can be read to try and figure things out, so there is no excuse for this. In the hands of people who just assume they know what they’re doing, however, these “easy” tools provided to them can create a monster.

I realize that I’m preaching to the choir with most of the people who read this blog, but it’s something that has driven me increasingly nuts over the years—all my hard work gone to waste, all the people who will continue to complain, or continue to live in the past with outdated technology. I know I need to stop caring, but the issue is that it makes me want to stop trying to help people. If people aren’t going to trust my expertise, or try to learn and adapt, then I don’t want to waste my time. I guess that I’m getting to the breaking point, and that’s very sad for me because this “thing” that I’ve been very good at for many years has combined both my intense urge to help people, and my love of technology.

I am always humbled by how much I don’t know, and it’s part of what drives me to continue learning more constantly. I’m starting to wonder though, what’s the use of all that knowledge if I can’t put it to work? What good is anything if it’s never used? Should I continue to spend half my time learning things that may never get used, or may never be lucrative? Or should I spend that time doing things I enjoy more, like reading books for pleasure, or playing video games? Up until now a great portion of my knowledge has only been useful in helping people in the ways mentioned above: fixing people computers, figuring out the little things that they cannot, providing resources and information to make work easier, showing them how to be more independent, and teaching them to use more tools. So if I don’t do that anymore then what’s the use of my knowledge?

You often hear of starving artists, but I’ve been a starving tech-geek for a long time. Jack of all trades, master of none, that’s me. I’d prefer to be thought of more as a polymath, but such people are not valued by the workforce anymore anyway. Employers want specialists, and yet I’ve reached a point where I’m afraid to “waste” my time becoming an expert in one particular field when there’s no guarantee of it being lucrative. I spent years trying to specialize in fields that have become obsolete, or in fields that just didn’t suit me. At the end of the day I have amassed lots of knowledge, but at the end of the day I’m still just a starving tech-geek.

What does a tech-geek do when they no longer want to play ball with the non-technical people, yet are incapable of being embraced by the rest of the tech community at large?

On Lying

2012-09-18T20:01:00Z

People think that a liar gains a victory over his victim. What I’ve learned is that a lie is an act of self-abdication, because one surrenders one’s reality to the person to whom one lies, making that person one’s master, condemning oneself from then on to faking the sort of reality that person’s view requires to be faked…The man who lies to the world, is the world’s slave from then on…There are no white lies, there is only the blackest of destruction, and a white lie is the blackest of all.
from Atlas Shrugged by Ayn Rand

Keep learning

2012-12-07T01:25:33Z

At times of change, the learners are the ones who will inherit the world, while the knowers will be beautifully prepared for a world which no longer exists.
Alistair Smith (via joshuakaufman)

“...at certain points in life I do things for a living.”

2013-08-07T02:50:58Z

I’m starting to find that my life’s journey of starting out as a hobbyist front-end coder to aspiring theatre actress to aspiring English major to Director of Operations at a non-profit organization to professional print designer to Computer Arts student to aspiring video editor to transitional user interface designer to project coordinator to aspiring professional front-end developer to aspiring full-stack web developer is actually a pretty common kind of transition.

Also…I have many skills.

I find myself reminded of this monologue from Working the musical. It’s always really resonated for me. Jobs are not big enough for people.

My Bootcamp Application Journey

2013-08-28T03:20:25Z

A lot of my closest friends have been following along on my private Twitter account with my career journey this year, but I can finally talk about it a bit more publicly. In February I decided that it was time to start pursuing my passions again and get back to working on my career in tech. My goal since December of 2011 has been to be a professional front-end web developer instead of just a hobbyist front-end web developer. To that end I spent a couple months of my unemployment trying to advance my skills at home independently. HTML and CSS have been in the bag since I was a teenager but I knew I needed to finally learn JavaScript and JQuery and build up a portfolio. Unfortunately, this wasn’t progressing as quickly as I had hoped, as the resources I was using to learn weren’t very great. In addition, I really needed a source of income, so I was spending a lot of time applying to anything I could find in order to pay the bills. After 5 months of unemployment I eventually got a job as an Office Manager at Viator, Inc and my career goals were put on hold.

Which brings us back to February of this year. I set some firm deadlines for myself and started spending my evenings and weekends doing tutorials online. I also started working on hand-coding a new website for myself (for the 10th time in the last year) to better represent myself. I was devouring every resource I could find on front-end development. I joined a bunch of meetup groups, some skillshare classes on JavaScript, general programming, and took a one month Ruby on Rails class on a whim (which produced this). I also did a pricey one-day workshop about iOS programming (which I was very dissatisfied with, by the way) because I was just so anxious to start learning everything about everything as fast as I could. I was advancing much more quickly then I was before, but I was really scattered trying to learn a billion of things at once instead of just focusing on one thing at a time. But through all these different resources I discovered something that didn’t exist back when I was working towards this goal while unemployed: web development bootcamps.

Web Development Bootcamps have been popping up like crazy over the last year. They are intensive full-time programs that aspire to help people become programmers. When I first started seeing information on these in March I thought, “Darnit, I wish they had these a year ago when I was unemployed!” and, “Too bad these are so expensive.” Then I started doing more research on Hackbright Academy and Devbootcamp, the first two that I had heard about, because I was dissatisfied with only getting to learn more about development here and there. I only have a couple hours of free time when I get home from work at night and in addition to coding I was also trying to plan a wedding, clean my house, run errands, and try not to neglect my fiance or cat. The more that I read about the bootcamps, the more I was convinced this is something I wanted to do. Realizing that I would have to quit my job to do this and fork out a bunch of money, I was extremely hesitant, but I figured that when it came down to it, it was a pretty risk-free deal considering the rate of employment after the programs is 93–95% (at Hackbright and Devbootcamp). And even though I’ve always been primarily a front-end coder, I’d been becoming increasingly interested in back-end languages. After considering it a great deal I brought it up to my fiance and as usual he was very supportive and said he’d do whatever it takes to help me with this new goal. So in March, I started working towards that course of action.

Once I decided that this was a definite course for me I wanted to start right away, but unfortunately with the wedding and then the honeymoon a month after that, it looked like I wouldn’t be able to start any of the programs until August or September. I was bummed I would have to wait but figured I’d continue learning all I could in the meantime and continued preparing and doing research. I also started discovering more bootcamps, like App Academy and Hack Reactor, and I realized in the midst of my obsessive research that I may not even get into any of the programs because they’re extremely competitive and receive a lot of applications. I had my heart set on getting in, so this was a hard notion for me. Here are the summaries of my experiences applying for each of the bootcamps over the last 6 months:

Hackbright Academy

Hackbright was my top choice so I spent weeks working on my application for them. There really wasn’t a lot you could put into the application form, but they let you submit a 2 minute video with your application and I recorded it over and over again trying to get it right. 2 days after my wedding I finally submitted my application, 4 ½ months before the session I wanted to do would even start. The application said they would initially respond within 2 weeks, but that’s inaccurate. I spent over 2 months chewing my nails, wondering if my application got lost in the ether. 2 months and 2 weeks after submitting my application I finally got an email saying that they would be reviewing applications that week (this was the 2nd week of July). Then 2 days after that I got an email saying that they wanted to do a video-interview with me and to schedule a time.

I really wish the interview would have been a technical interview instead of a social one. I was so nervous that I’d bumble it and be my normal socially inept self, whereas if it was a technical interview I could have shown I was a good candidate. The interview was conducted by Liz Howard, who I recognized as being the teacher of some of the meetup events I had attended. She asked me why I was interested in the program, and I was able to answer that well enough. She didn’t really ask me a lot of questions though, and I didn’t really feel like the interview was going well. It lasted about 10 minutes and at the end she said, “Okay, well I’m going to pass you along to Christian to do a technical interview, and you’ll be receiving an email in the next couple days to schedule that.” So I was elated thinking, “Yay, I’ve made it to the final round and this is finally going to happen and happy joy joy!”

But the next day came and no email, and then another day passed and no email. Finally, 4 days after the video interview, I received a form letter rejection saying that they would not be moving forward with me as a candidate, which made me extremely upset because 1) the form letter didn’t even have the correct cohort session that I was applying for and 2) I was told by Liz that I would be moving on to the next step. I felt it was kind of cruel to say that and then not follow through. The email also said that I should try to apply again in 6 months, but after already waiting 6 months to do it in the first place, this was a really big blow. I know they get a lot of applicants and I know they can’t possibly accept everyone, even good candidates, but I couldn’t help but feel bitter every day for the next week when I saw them tweet, “The deadline for the next cohort is in one week. Apply now!” I ended up muting them in my twitter feed for a couple weeks because I kept getting really depressed about it. So that was the end of trying to get into Hackbright.

Devbootcamp

Originally, Devbootcamp was going to be my backup if I didn’t get into Hackbright Academy, but I had waited too long to submit my application because I was hoping to hear from Hackbright, and also because I didn’t think I could come up with the money as fast as Devbootcamp required, if they accepted me while I was waiting to hear from Hackbright. In the end, waiting made the decision for me, because in the 2 months between when I was going to apply and decided to apply, the program filled up for the entire rest of the year. So it no longer was an option. In the end though, I’m not sure that I would have been happy with their particular program, the more I’ve read about it I don’t know if I would have fit into their culture well, and with it only being 9 weeks, etc.

App Academy

At first I considered App Academy a worst-case scenario because while the price tag is attractive (you pay nothing until you get a job), they didn’t seem to be as good of quality as the others. I was also extremely hesitant about them because their website was horribly out of date. It only had statistics for their first class, from a year prior, and that wasn’t even the same kind of class they were teaching now. On top of all that I figured they were probably even harder to get into because of the deferred payment option. But after 2 months of waiting to hear back from Hackbright I thought I should go ahead and apply to App Academy just in case. They emailed me back the very next night (a Sunday) with a link to a timed coding challenge and some recommended prep-work to do before the challenge. They said there was no deadline to complete this. The next night after work I got started on the prep-work, which was a bunch of beginning Ruby exercises. Due to my limited free time after work, I had not yet finished all the prep-work by the end of the week but got an email from them saying, “Why haven’t you completed the coding challenge yet?” We had a wedding to go to that weekend so I didn’t have a lot of time to finish the prep-work then either.

On Monday night, the same day I did my video interview with Hackbright, I decided I needed to just hurry up and take the coding challenge even though I wasn’t comfortable with Ruby yet. That was an extremely stressful 45 minutes. There were 3 problems that you had to complete and you weren’t allowed to google to look anything up. These were problems I could have easily done in JavaScript, but I wasn’t able to complete a single one in Ruby. I worked through them over and over trying to find the solution but half my problem was I kept forgetting what would be the correct syntax for Ruby. In hindsight I wish I would have just googled for help anyway, since it was syntax throwing me off. In the end I submitted my incomplete code to at least show an effort, but I knew I blew it. I was mad at myself for rushing into it and not studying more.

The next day I received an email saying that it looks like I don’t have much programming experience (No App Academy, I just don’t have much Ruby experience, which is what I would be learning in your program). They then gave a list of books and tutorials saying, if you do all this work then we’ll review your application and MAYBE let you in. Some of the books cost quite a bit of money, and it was about 50 hours of work, and there was no way I was going to have enough time to complete it all by the deadline, with no guarantee of even getting in at that point, so I didn’t pursue it. A week later they updated their program and their website, making the course longer and more expensive. I still had my doubts about them and the increased price tag made me kind of glad I didn’t get in anyway.

Hack Reactor

After being rejected by both Hackbright and App Academy I started to have doubts about whether I was cut out to do back-end development. I had always worked on front-end and maybe I should stick with that. I started exploring my other options and took another look at Hack Reactor. I had barely looked at them months before because all I saw was their high tuition price. They are definitely the most expensive program by far, but then giving them a fresh look, the more I learned about their program the more I realized that it’s the program I should have been working towards all along and I was mad at myself for not trying to get into them sooner. The reason they’re so expensive is because the value of their program is so much higher, their program requires more hours of your time, and they achieve top results (100% hiring rate). On top of all this, their focus is on JavaScript. Initially all I had set out to do was master JavaScript, so this focus was much more aligned with my goals. My excitement was renewed and I applied to them the night I got the rejection from Hackbright. I was worried about being able to afford it but thought I’d worry about that later. They also have an extremely competitive application process with many rounds of interviews so I was mad at myself for giving JavaScript a break to work on other languages etc.

I received an email 2 days after I applied saying that they’d like to have an in-person interview with me and I was excited that they responded so quickly. I scheduled the interview for the following week because that’s what worked best with my schedule and it would give me time to brush up on JavaScript since I hadn’t been using it for a couple months and they would be testing me on it in the first interview. Working on JavaScript that week was a breath of fresh air after doing Ruby. The Hack Reactor interview was scheduled during my lunch hour at work. I was very nervous but showed up intent on doing well. But when I got there it turned out that they had double booked interviews and asked if I could wait 20 minutes. I said yes and sat down on the couch watching the clock so that I wouldn’t be late back to work. After waiting for an hour I couldn’t wait any longer and went back to work. Once I got back to my office I got back on their calendar link, which luckily I had saved and selected another interview spot right after work that day.

I headed back over and sat back down and waited for someone to notice me. Finally Tony came out and said, “I wondered what happened to you.” I explained to him how I had to get back to work, and that I had rescheduled, so he invited me into the office and started the interview. He asked me to do a JavaScript problem on his laptop while he went to get a drink from the kitchen. I felt under pressure to do it quickly and ended up making a bunch of stupid mistakes that I normally don’t make at home. He was very friendly, however, and explained to me what I did wrong, how I could make the code better, etc. After doing the problem he talked to me about the details of the program and answered any questions I had. At the end of it he offered me two choices. He felt that I wasn’t as ace at JavaScript as I should be, and he could give me a guide on learning and getting better and then I could come and meet with him again, and then do a technical interview. The other option was just going ahead and scheduling the technical interview. It was a hard choice but I was anxious to get started soon and I knew I should push myself instead of playing it safe, so I chose the latter. The technical interview was scheduled for a week and a half later, which is the week after I was going to Ashland for the Oregon Shakespeare Festival.

Part of preparing for the technical interview was doing their chatbuilder app, that they sort of walk you through the steps for, but you have to figure out the code to write. I spent my entire vacation working on it, and at first was feeling very overwhelmed and discouraged, but then I took another stab at it and did lots of research and parse api tutorials and then I felt like I could write it from scratch, but I still couldn’t write it using their tutorial. I just kept working away at it, and eventually I actually got it working and had it almost completed. But I was having lots of anxiety about the technical interview, and I was really worried about being able to physically handle the 6 day/all day program that Hack Reactor does, because of my chronic fatigue problems. Combine this with not being able to afford the program, and I ended up canceling my technical interview. I had lots of regret about canceling it, thinking I should have at least found out if I would have been accepted or not. But the fear of failure was really strong because I wanted to get into their program so badly, and I thought it’d be too hard to say no if I was accepted.

It’s unfortunate. I think their program is the best and I would have loved to do it, but after trying to get a personal loan for another program, and having trouble getting a much lesser amount, I know I never would have been able to afford Hack Reactor’s tuition. So that’s that.

General Assembly

Even though I had known about General Assembly for a long time through my meetup groups, I hadn’t thought of them as a bootcamp since all the articles and comparison charts that talk about bootcamps never mention General Assembly. I knew they did some online courses and some workshops, but that was about it. After being rejected from App Academy and Hackbright Academy and trying to explore what my other options are, I delved into research on General Assembly trying to figure out if they were a worthwhile option to consider. They started out in New York City, and now have about 8 different bootcamps all over the world. They don’t just have one area that they focus on, which worried me a little, but the program that I’d be doing through them is their Web Development Immersive. Something else that concerned me was that I could find lots of information about the New York City one, but not the San Francisco one and another thing that made me hesitant is that they’re the only one that doesn’t have a hiring day, or job placement rates, because they’re not as job-focused and make no guarantees. After the rejection from Hackbright and App Academy I decided to go ahead and apply, since I couldn’t afford to rule out any options.

They emailed me back a little over a week later saying that they wanted to schedule a phone interview. Luckily I was about to start my vacation so I scheduled the call to take place the first morning we were in Ashland. The call lasted about 25 minutes. I spoke to a man named Danoosh and he asked me some questions about what my goals are, and if I understood that this was a full-time program, etc. He also asked if I was a good typist and what my prior skills are in programming. He then let me ask questions, and I asked how many students were in each cohort, and some more general questions like that. The call went well and he said he’d be emailing me a sort of “test” for the application process and that I would also need to schedule my in-person interview.

The test was that you had to use html and css to make a one-page “About Me” site that included a photo and a summary, and then you had to email the files to them 48 hours before your in-person interview. I thought, “Well that’s easy!” and instead of just sending them one of my dozens of “About Me” websites that I’ve done over the years I decided to do something from scratch that is completely different from my other stuff. They said not to spend more than a few hours on it, so after a few hours I forced myself to stop trying to make it perfect, and got back to working on my Hack Reactor chatbuilder web app. I ended up liking my super colorful webpage so much though that I’m considering changing my live site’s theme. Here’s the quick page I made for them.

My in-person interview was scheduled for 1 ½ weeks later on a Friday evening. I was very conflicted and hesitant about them still though, and was hoping to get into Hack Reactor. General Assembly is the only bootcamp in San Francisco that doesn’t have computers on site for you to use. All the other ones tote their pair programming stations as one of the benefits of their programs. I find this to be one of the reasons General Assembly is less desirable because you’re paying the same amount as the others but not getting as many benefits. I’m lucky enough to already have a computer to use, but the point is that it’s nicer (and easier) to work on large monitors, and that wouldn’t be an option at their school. They are also much further away from public transit than any of the other bootcamps. But I eventually found the GA San Francisco twitter feed and read the entire thing and that helped me get a tiny bit more sense of how the program is.

I started considering taking the money I would be spending on a bootcamp and just using it to quit my job and stay home learning independently. I would actually save money that way and could focus on learning the languages that I was most interested in, and not wasting time with things I already know, etc. I developed a plan and a budget to weigh that as an option, but my husband was not crazy about that option. I didn’t think it was optimal either; I wouldn’t learn pair programming, or gain whiteboarding experience, etc. But I was worried I wasn’t going to get into Hack Reactor and I wasn’t convinced General Assembly was worthwhile. A few days before my in-person interview with General Assembly I just decided to email them, point blank, to address a few of the things that were worrying me. I asked them who the instructors are, how much 1 on 1 time you get with them, and what are the employment statistics for people who’ve gotten jobs after attending the WDI program in San Francisco. He emailed me back and said that he didn’t have information in the instructors yet because they were still hiring for the next session. He assured me that the instructor to student ratio is very good, and he said that 100% of people who were looking for jobs after the program got the outcome they wanted, and then emphasized that a lot of people who do their program are not looking for jobs and are just wanting to learn the skills.

His response made me feel a little better about it and I stopped having as much anxiety about the quality of their program, but it still seemed like it was too easy of a program to get into and that it wouldn’t be the level that I needed. The night before my in-person interview I started testing myself on brain teasers and logic puzzles online, because it said on the website that they’d ask some brain teasers. The next morning I woke up feeling so sick that I threw up (something that I haven’t done in years!) and so my husband immediately demanded that I call in sick to work. I laid in bed all day long while Jesse nursed me, but there was no canceling my 5pm interview with General Assembly, so I trekked over to the city with my laptop and tried not to think about my illness.

For my in-person interview I met with Anil who is one of the instructors. He asked me a couple questions about my technology background and I told him about the first time I saw a computer and how it was love at first sight. We pulled up the web page I made and talked about it. He really liked that it was colorful. I told him that I did that because it was opposite of how I usually design my live sites—I prefer simple and somewhat monochromatic. So then he pulled up my live website and complimented me on how clean it was. When I told him that I had been learning JavaScript this year, he asked to see a project. I told him that I didn’t really have any projects to share but that I was in the middle of working on the chatbuilder web app for Hack Reactor, so he asked to see that. I walked him through what I was doing with it, explaining the different parts of the code and what I still have left to do and he waved his hand and said, “You’ve got this. You know all this stuff.” He then asked if I had any questions and I asked a couple logistical ones. I also asked how much time they spend on HTML & CSS since I’m anxious to move on to the stuff that I don’t know how to do. He assured me that it’s very minimal, and that it’s not a front-end course. I found out that they have a couple female instructors, which I found very encouraging and pleasing. He asked me if my husband understood that he wouldn’t be seeing much of me and I assured him that Jesse is already used to me spending most of my time programming and that he’s very supportive. He didn’t ask me any brain teasers and overall the interview didn’t last long. We finished and he said someone would get back to me soon about whether I am admitted or not.

The next evening, a Saturday night, I got an email from them saying “Congratulations! You’ve been admitted.” So, I’m going to General Assembly! The next day I canceled my technical interview for Hack Reactor for the reasons stated in that section, and then spent the next few days trying to get a personal loan. Once that was all taken care of, and tuition paid, they sent out the pre-work that has to be done before the program starts, and I’ve been focusing on that for the last week.

There are certainly other bootcamps that I could have applied to in other cities, but it would have been more expensive to have to pay for housing elsewhere, and I didn’t want to leave my new husband for that long. If I hadn’t been accepted by anyone, I would have continued learning independently and strove towards a ThoughtBot Apprenticeship. With any of these programs though, you get out of it what you put in, and I intend to make this experience the best one possible.

What does this mean now?

It means that I will now be able to dress however I want again, and look however I want again, so be on the lookout for some fun hair colors ;-)

More importantly though, it means that I will be focusing really hard on the program to do my absolute best and insure my success in gaining a job afterwards. The program inherently is an intensive course; that’s the whole point. I will have homework and I will have very little free time between the dates of September 23rd to December 19th. Additionally I’m going to be a starving student for the next 4 months and will be saving every dime that I can. No more Rdio and Netflix for me (not that I’d have the time for movies anyway), and I’m going to be eating lots of ramen. I was even going to let my car registration expire and file planned non-operation since I won’t be using my car at all for the next few months and could save money that way, but unfortunately I found out that you have to have a garage to store the car in, so am ending up having to renew it at the last minute; boo on not getting to save that money.

I have warned all my close friends and family to not expect to see much of me during this period of time. The program suggests regular blogging of the experience and what we’re learning, so anyone interested in updates and how things are going should follow along here. Also, if you’re a friend interested in getting together with me before the program starts, please let me know! I’ve got a running list.

I’m really looking forward to this new adventure and finally getting to pursue my passions in a more direct way. I’m bursting with excitement and counting down the days until I get to start.

Meetup Group Drama

2013-09-04T23:09:55Z

I am a member of the SF Ruby Meet Up group. Today I checked my email and saw a message thread from the group that made me feel sick to my stomach. A woman had sent a message to the group saying that she was looking for women developers for an internship and those interested should email her. The first couple replies were very reasonable ones from men giving her a heads up that it is illegal to discriminate based on gender, and that they would recommend not listing genders in job postings. These replies weren’t attacking her, they were factual, and she immediately sent a reply apologizing for the mistake and welcomed those of all genders to apply. Everything’s cool then, right?

It’s all the messages after that one that sickened me. A ton of replies from men attacking her for discriminating against men, saying that she was going to just discriminate in secret now, and that she’d choose a female over “the more qualified candidate.” They even pointed out that most of the group is men. She tried yet another apology but they just rolled on over her. Some of them tried to act like they were just being funny but none of it felt funny.

No women had replied to this thread and I very much wanted to. I agree that there shouldn’t be discrimination against men OR women in tech, and I was going to state that, but I was also going to point out that it would be nice if the men could start being that outraged about the heavy discrimination against women in tech every single day. That what WE deal with is so often “secret discrimination” done behind the scenes, and maybe it would help offer a little perspective. I starting typing out a response a few different times, but that little voice in the back of my head said, “Do you really want to do this?”

I realized that it doesn’t matter how logical or reasonable what I say is, I’m going to be attacked for it, so what would be the point? So I didn’t say anything and I’m very tempted to leave the group because those aren’t the kind of people I want to interact with. Then I thought about it more and realized that this is a major part of the problem—that women feel like they can’t speak up because no one will listen and they’ll just be attacked. THAT is discrimination rearing its ugly head. I felt unable to speak up, and I felt like I should leave the group, because that solves the problem right? I’ll just let myself be chased away.

It would just be nice if people could be reasonable when speaking with each other. If your coworker makes a mistake, do you attack them for it? Or are you constructive and help them learn? I realize this is the Internet, and it’s a breeding ground for the type of people who like to hurl insults from the comfort of their own home, because there’s no repercussions; that’s not going away any time soon.

I’m just saying that it doesn’t really help your argument if you act like a douchebag. I’m certainly less inclined to want to work with the type of men that were posting on this thread.

Update: A woman with more guts than me posted at the end of the thread a very positive reply congratulating the poster for promoting more women in tech and pointing out that this is something to be celebrated. This only provoked even more ignorant comments from the men about how women in tech aren’t oppressed and that way more men want to be programmers than women, and someone went as far as saying that men are better programmers. DONE. Can’t deal with those uneducated assholes.

Update 2: In reflection I probably shouldn’t call those guys assholes when I’m complaining about people hurling insults at each other. They’re being unreasonable, and their attacks aren’t nice, and they have displayed a large level of ignorance about the discrimination of women, but maybe they’re not assholes all the time. Maybe deep down they’re nice people who just need to gain more perspective.

Update 3: It ended up racking a large amount of replies, and towards the end there were a few men being wonderful advocates trying to educate the ignorant on the very real issue of women being oppressed in tech, and posting links to statistics, etc. It gave me hope that there’s light at the end of the tunnel.

Last Day at Viator

2013-09-13T23:26:22Z

Those at Viator who voted in the 2012 election showing off the stickers

Today was my last day at Viator, Inc. It’s a travel company that helps people research and purchase tours & activities in hundreds of travel destinations all over the world for the lowest price, guaranteed. I worked there for a year and a half and thought I’d go over some of the highlights of my time there:

The opportunity to get to learn so much more about the world we live in has been incredible. I’ve always been interested in travel and learning about other cultures, but I cannot imagine that I would have ever learned half the things I did about other places in the world if I hadn’t worked there. My knowledge of geography has increased exponentially. Being an overachiever, I had to map out the entire world when I was 12, but it only included all the countries, states/provinces, and their capitals. I’m now familiar with regions of countries, and non-capital cities of countries, and what the climate is like in those regions, what kinds of things people do there, what the popular attractions are, etc. My head is bursting with this knowledge about our world, and I love that.

I’ve also now seen thousands of pictures of places, people, food, animals, etc from all over the world and it’s given me a greater appreciation of just how much beauty you can find wherever you travel. A “downside” of this is that it’s also increased the list of places that I’d like to see in person to a overwhelming amount. The list of other countries that I wanted to travel to used to be only 2 or 3. It’s now gotten so long that I have had to make priority, secondary, and tertiary lists.

I’ve also gotten to meet many new people from other countries and be around so many different languages on a daily basis. Again, I loved that. One of my French coworkers would Skype me in French, and occasionally talk to me in French, because she knew that I wanted to brush up on the language. I regularly made a fool of myself to my Asian coworkers demonstrating the Japanese I know from watching so much anime when I was younger, but they seemed to get a big kick out of it. My coworkers were constantly traveling for both business and pleasure and everyone would always bring back some kind of treat from the place they visited. I now have an addiction to tim-tams, which come from Australia.

More of a perk than a bonus, a highlight was getting to experience things in San Francisco with Viator on company outings that I normally wouldn’t have otherwise. Some of our trips included: wine tasting tour through Napa Valley, cruising around the bay during Fleet Week, and going on a hop-on/hop-off bus through part of the city while getting the “real” commentary since we are locals.

And last, another highlight was the company’s official colors being bright orange and bright blue. It might be silly, but I couldn’t help but smile on a regular basis at the orange and blue walls in the Viator’s San Francisco office. I will miss those walls.

WDI Orientation

2013-09-22T04:43:47Z

Tonight we had the orientation and installfest for WDI. It was really great to finally put some faces to the names I’ve been seeing on the contact sheet for the last couple of weeks. I was especially excited to see our instructors and learn more about them. We were separated into two groups and I was put into the Snakes Brigade (which makes me think of the House of Slytherin). I was a little disappointed because all the people I had already befriended were put into the Camel group, but I’m sure once I get to know everyone in my group, I’ll be just as happy. I mean one student in my group had a Totoro decal on her laptop so she’s already my new favorite person.

At the beginning of the orientation the producer, Annie, congratulated us all on getting into the program. She said that they made the admissions harder in between the last cohort and this one, and that this was the most selective they’d been so far. That definitely gave me a little boost. There are also a lot of students that aren’t from the Bay Area, including a couple Europeans, which is pretty neat.

Class starts on Monday, at long last. So far it almost hasn’t really felt real yet. Looking forward to the first day of the rest of my life. ;-)

WDI Day One

2013-09-24T23:35:44Z

Yesterday was the first day of class. I arrived out of breath and sweaty from my exertions of trying not be late on the first day. Normally this would not be an issue but for some reason all three public transit methods from Alameda were backed up today. It’s the first time ever that I’ve seen the parking lot at the ferry terminal in Alameda completely full.

I was nervous about the first day, not knowing what to expect, and worrying that I’d be lost. This wasn’t the case, and I was actually bored most of the day. I think I would have actually preferred the former, but the instructors have assured us that day 2 is going to move at a much faster pace. I was mainly concerned because everything they went over on Day 1 was easy stuff from the pre-work that everyone already knew, and yet the Camel class was way ahead of us.

What I did learn, however, was how to finally fork something on Github and submit a pull request. I’ve been using Github to track my own repos for the last 6 months, but I was a little intimated by trying to interact with other people’s repos, so had never tried forking and pulling before. I also learned some useful commands for text editors that I didn’t previously know, like using ‘command-/’ to comment out a bunch of text (or uncomment). I also learned the command to go to the end of the line ‘ctrl-e’ which is going to make my workflow so much faster. I should have looked up these shortcuts way sooner. Minor things, but at least the day wasn’t a complete loss.

We were assigned homework, and the majority of it was so easy that I had it done before class even ended, but there were 2 problems that ended up taking me 3 hours to do. One of them was the evil prime number function that so many programming languages test you on. I know it’s a common test, but I’ve always had trouble with it. Now of course, the dirt simple way to find all the primes from 1 - 100 in Ruby (which was the question) is to simply do this:

require 'Prime'
    
Prime(100).each do |x|
  puts x
end

Done. There you go. But I’m pretty sure they wanted us to do things the manual way and I struggled with it. I know what primes are, of course, but I ended up reading so much documentation on prime numbers and the different algorithms that mathematicians have come up with to find them, and I even looked up examples of what other people do to find prime numbers in Ruby (without the Prime class), but I still couldn’t get their examples to work. In the end I ended up doing a really sloppy function that worked but I know is not ideal.

The last problem on the homework was something that one of our instructors said he actually got during an interview. We all struggled with it and were talking about it on HipChat late into the night. It took me an hour to solve it, and it works, but isn’t the cleanest solution. I’ll probably refactor it to make it better.

The problem:

Use a pattern and consolidate the amount of characters into a simplified string.

input pattern = “AAASSSDDDDRDDSASSDDDSSSAD” output pattern = 3A3S4DR2DSA2S3D3SAD

If a character is represented more than once, append the number of occurrences in front of it. If a character is only represented once, just put that letter.

Hint: Use a loop to iterate over a string. You can reference characters in a string similar to an array.

My solution:

input = "AAASSSDDDDRDDSASSDDDSSSAD".split(//)
output = ''
char = 1
counter = 0

while counter < input.length
  input.each do |num|
    if input[counter] == input[counter+1]
      char += 1
    else
      output << char.to_s
      output << num
      char = 1
    end
    counter += 1
  end
  output = output.delete '1'
end

puts output

WDI Week One

2013-09-29T03:03:55Z

As I suspected, blogging every day was impossible; too busy with homework. So here is an overview of the week.

Tuesday — Arrays, Hashes, JSON

We went over the homework in the morning, and did some more exercises. The focus was on arrays, and I learned a couple new useful methods. I had been using the .rand() method to get random items from an array, but it turns out that the array class has its own method called .sample() that does the same thing in a much simpler manner. In the afternoon we did a lab project where we had to use Ruby to extract data from a JSON file. We also were told about a great browser extension called JSONView for making JSON easier to read in the browser. It’s also handy for showing you the path of a line item at the bottom of the screen. I’ve worked with JSON once before in the chatbuilder app for Hack Reactor, so I had a basic idea of what we were supposed to be doing, as far as accessing the values. I really enjoyed the lab, since working with JSON is one of the things I’ve been wanting to reinforce in my head. After class, Jack Danger from Square came to talk to us about engineering, the work environment, advice, etc. and I found the talk very encouraging and inspiring.

Jack Danger from @square is here to talk to us :-) (@ General Assembly - @ga_sf) [pic]: http://t.co/Seoc2hlzxt
— Amy MacKinnon (@ThatAmyMac) September 25, 2013

The first part of the homework that night was mostly easy and I had finished it all in class except for a single problem that I ended up spending a couple hours on. I scoured both the arrays documentation and the hash documentation trying to figure it out. All we had to do was compare 3 arrays to find the number that was common to all of them. I kept trying to figure out how to loop through and compare all the items, but no method I was coming up with really seemed logical. I finally posted to HipChat to see if any of my classmates had figured it out, and one of the instructors started giving me hints, but another classmate said, “Just use &.” I looked at the Array docs again and realized that up above all the word methods there were operators that I had been ignoring. If you use & to compare two arrays, it’ll return the common items. Easy as pie! Example: [3, 5, 6] & [5, 7, 2] will return [5]. I felt like an idiot for not finding that method sooner. Needless to say, I now look at all the operators too.

The second part of the homework was tricky. We were given 4 subway lines that intersect at Union Square and had to be able to take input of where a user was getting on at, and getting off at, and tell them how many stops until their destination. I spent a couple of hours on it and got a fair amount done, but there was one thing tripping me up that I didn’t know how to solve so I finally went to bed around midnight. About 5 minutes after going to bed I was laying there explaining in my head to my instructor the issue that I was having and a lightbulb appeared (Yay Rubber Ducky debugging!). I excitedly grabbed my iPad from the nightstand and started jotting down the solution with my stylus in Penultimate, and went back to sleep. The next morning before school I got it working and quite happily submitted my homework before heading out to class.

Wednesday — Methods/Functions

The morning was kind of slow again, as we went over methods, but the afternoon really started to pick up and provide some challenge. They combined the Camels and the Snakes and split us up into two groups. One group was going to go do review and the other was going to do some more challenging exercises. I chose the latter, of course. We worked through some exercises, such as testing whether a word is a palindrome. I started to solve it by doing looping and comparisons, and then I stopped and went, "Wait! Can’t we just compare the string to the string reversed? Such as: puts true if string1 == string1.reverse? Alas, about 5 minutes after I had that “Duh!” moment, the instructor notified us that we can’t just take the easy route, we have to do things the manual way. Luckily I had only commented out my original start to the solution, so I finished it up and was able to get it working the manual way.

After doing a couple more exercises like that, the instructors told us that the next challenge was to create a ‘Choose Your Own Adventure’ game. I excitedly clapped my hands and said, “Ooohh, I’ve created a couple Choose Your Own Adventure games because it was required in Learn Ruby the Hard Way!” (Which we had to do for pre-work). The instructor said that their requirements would probably be harder, but when I showed them what I had made for the LRTHW exercise, which you can see here, they said, “Well obviously you don’t need to do this exercise.” So they asked me if I’d like to instead go through and refactor my code? I agreed most heartily since I’ve been wanting to continue to make the game better as time goes on. So I spent the next hour going through cleaning up the code, and decided to start tracking it through git.

Classmates working out code on the window.

Our homework assignment was to create a calculator app to run in the command line. I figured it would be pretty easy so I left class right away to head home. The calculator was in fact easy, but it took me over two hours just to type it all out. Once I got it in a fairly good working state I cuddled up to watch an episode of DS9 with my husband. He laughed at me because as soon as it ended I sat back down at the computer to fix some bugs. He went to sleep and I only continued working for about 5 minutes more before deciding to prove to him that I’m not an addict, and went to bed. In the morning, however, I chose to fix the bugs in my calculator app instead of using my time to eat breakfast before class. Dedication.

Thursday — Culture, Github, and Classes

This was the day that tiredness was really starting to set in. The first part of the morning we were asked to get into our small sub-groups of buddies to brainstorm on culture for the classroom, since we hadn’t gotten to that the first day. Every group had to go up and add to a list of what we thought was most important for the culture of our class. A lot of it kind of goes without saying, but I think it was a good reminder to people to be respectful, honest, encourage each other, etc.

We went over our calculator homework after that and a couple people went up to present their solutions. One of my classmates, Santiago, made one that just blew all of us away; it was gorgeous. He had formatted it in such a way as to be really readable in the command line. A couple other people presented who didn’t follow all of the instructions, and then our instructor showed us her solution, which also didn’t follow all of the instructions. I was a little annoyed with this because I tried to follow them exactly, and would have probably done things a little differently if I wasn’t under the restrictions of their steps, so I raised my hand and asked if we’re supposed to take the homework instructions literally, or can we deviate? They said we don’t have to take them literally, so I’m definitely going to start coding things the best way I see fit, and not get too hung up on being so precise.

I also didn’t realize it at the time, but no one is looking at my homework anyway. I am one of the only people who has had a pull request open the entire week for my homework. It just isn’t getting looked at and merged in, and it’s so lengthy now I’d be shocked if they bother to read all the files and commits.

After that, one of the instructors, who is pretty much the resident Git expert, went over Git and Github again with us, and how to submit our homework. I guess some students were pretty confused about it, which is understandable because I remember being confused and frustrated when I finally started using Github last February. At first I was going along and doing the exercises with the class because practice makes perfect, but then he had to go into some massive explaining of how it all works and ties together, using lots of drawings and visual representations, and so I started working on my own stuff at that point. All in all the whole Github thing took over 2 hours and I was feeling very drained and grumpy by the time it ended. Yay for lunch time to rejuvenate.

After lunch we started going over Classes and Inheritance in Ruby. This is also something I had already learned in the pre-work but I was happy to do the exercises because Classes are so important and practice makes perfect (I’ll be saying that a lot). We did a few exercises about how to create Classes, inherit from other Classes, use attr_accessor, and so on. I spent the latter half of the afternoon trying to remember how to use the splat operator properly for unknown amount of parameters in method arguments. I remember learning about how to do it when I did the Ruby tutorials on Codeacademy but I was having trouble remembering how to access it if you have multiple arguments. I’m hoping this will be gone over in class at some point, because I think it’s very important for using methods to their best potential.

The homework assigned seemed like it was going to be very quick and easy (as opposed to just easy like the Calculator app was) so I decided to stay after class to get it done before heading home and let rush hour commuters clear the streets. I rebased the upstream for the homework repo and started to get to work, but then realized the rebase didn’t actually finish. There were merge conflicts. I had my first “working with another person’s repo” headache. I started looking around for our Github expert instructor to ask for help but I didn’t see him anywhere and he wasn’t on HipChat so I started trying to figure out what I needed to do, on my own. Luckily the error messages are pretty informative so I was able to deduce that I needed to open up the files that had “warning” symbols on them (and were mentioned in the errors) and edit them. I managed to finish editing 3 of the 4 files that had merge conflicts, when the instructor appeared to help. He aborted the rebase and helped me go back through everything and make sure things were good. I asked him for any tips on how to make sure this doesn’t happen again in the future, but neither of us really knew why the merge conflicts happened other than he said there had been some Github weirdness that week. Either way, I’m glad to have him as a resource if it happens again.

So that all took 45 minutes and then I finally got started on the homework. We had to create a blender method, and then a blender Class. I did the method pretty quickly, and had just started on the Class when a classmate came over and asked me for help. I told her I hadn’t gotten to the part she was asking about yet, but that I’d be happy to help once I tackled it. A few minutes later I had finished and went over to help. All the instructors had left for the night so it was just a few of us there working away. I spent about 10 minutes helping to walk her through it and it looked like it was working, so I started to go back to my seat, and then another person asked for help. So I helped that guy and then went back to my seat to wrap things up. Right after sitting down though, another classmate asked me for help so then I went and helped him too. He used regex in his app! I’m kind of scared of regex right now, but mainly because I haven’t really sat down to learn and understand it yet. After I was finished helping everyone out, I pushed my homework up (to Github) and headed towards home. At this point, it was about 8pm, so I was kind of amused that even though it was the easiest homework of the entire week, I had managed to spend 2 ½ hours after class just trying to get it submitted.

I’m starting to learn that I really like helping my classmates, and explaining concepts to them, because it helps me fully understand things better, it helps me learn to communicate more effectively—which is something I definitely have needed to improve—and I have always enjoyed helping other people, so everyone gets something out of it. I’m not the best communicator in the world, and I have often thought that I suck at explaining things, so the more practice I get…the better! ;-)

Friday — Exceptions

I was officially exhausted by this day. I was so drowsy and coffee wasn’t really helping. This was also the first day that I had a really frustrating time in class. I think this was directly correlated to my tiredness. After going over the homework, we started learning about Exceptions (error handling). I paid full attention to this, because while I had started to see some stuff about Exceptions in the pre-work, this was not a subject I was fully comfortable with yet. We were told about the ninety-nine percent rule:

"The first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent of the code accounts for the other 90 percent of the development time." Tom Cargill, Bell Labs

After the initial Exceptions lecture, we worked on a lab project and this was where I got really frustrated. I spent about 30 minutes just beating my head against a wall, not able to figure out how to get things to work. One instructor tried to help, but I don’t think she understood me when I explained what I was having trouble with. I continued to beat my head against a wall, and thought that I just wasn’t getting the Exceptions stuff at all. It turned out that the Exceptions stuff wasn’t my problem. A simple loop that wasn’t performing correctly was my problem. I couldn’t figure out why this simple loop wasn’t working:

def allergy_test
  @stomach.each do |food|
    if food == @allergies
      @stomach = []
      raise AllergyError
    end
  end
end

I tested all the objects involved to make sure that it was outputting what I thought it was outputting, but it turns out that by using puts to test instead of print I wasn’t realizing that the stomach array was actually an array within an array. It took one of my other instructors coming over and helping me to figure that out. It was just a matter of flattening the array before doing the loop. After that I had a raging headache and was so angry with myself for getting stuck on a stupid loop. I’m sure I came across as really grumpy too when the instructor was helping me, and so I felt bad, because I wasn’t grumpy with her, I was grumpy with the code. Hopefully she understood. With the loop problem solved, I had the custom Exception working within 5 minutes. It ended up being so anticlimactic and easy; I felt like there should be so much more to it after struggling all that time. I sat back and took a deep breath and then got myself some ibuprofen.

One of the past instructors of the program had a Google Hangout with us from Berlin to chat and give us advice. I was extremely disturbed by the fact that he was the complete doppelgänger of an ex-lover of mine from Virginia. I mean seriously: identical. During lunch I actually wandered outside and found a bunch of my classmates hanging out in South Park. I joined them and basked in the sunshine and was thrilled I finally had a chance to do some socializing. I bring my lunch from home every day, whereas most everyone eats out, so it’s been tough trying to make friends.

After lunch we had a !Quiz (not Quiz), where we could go over what we had learned all week to determine how comfortable we were with everything. It wasn’t going to be “graded,” and was mainly for our benefit, but we still had to fork the gist for it so that the instructors could look over it. I sped through most of it, but as I got towards the end I got stuck on a loop again. Loops were not my friend on Friday. I was trying to do a loop within a loop and it just wasn’t working the way it was supposed to. Finally I just did a single loop and incremented the index of an array, and got it working, but then our time ran out for the quiz. I need to learn to move on to the easy problems when I’m stuck, because I continued working after the instructor got up and started to go through the beginning and finished the rest of it really quickly.

We once again got to join with the Camels and then split into two groups to work on separate lab projects. Though I was exhausted and grumpy I chose the more challenging one, because it’s me, and I’m a masochist. It was already after 4pm at this point, and the weekly General Assembly Happy Hour was going to start at 5:30pm. We had to create a Tic Tac Toe game in the command line. The instructor showed us an example of the final product, and gave us instructions and told us to go forth. He also assured us that this was not something we were going to get done tonight, that we would need to work on it over the weekend as homework, and that none of his students had ever completed it in less than a day and a half.

I pulled out my notebook and was going to start strategizing when my classmate Shindo, who was sitting next to me, started talking to me about how to go about solving this. We started throwing ideas back and forth, and my brain was so fuzzy at this point that I was being very ineloquent, but we discussed what the proper course of action would be, and wrote some things down in the notebook as examples as we were talking through it, and then we started to code. We hadn’t really said we were going to work together; it just kind of happened. This was my first time truly pair programming, and it was magical. I’m a believer now. We worked on it together, letter by letter, talking through everything, typing in the same code, and keeping each other in check.

Happy Hour at GA from the viewpoint of the classroom we were in

The result of this was that 30 minutes before Happy Hour started, we realized we were somehow accidentally almost done creating the game. It was at that point that we were like, “Holy f#@k! We might actually finish this tonight.” We then became really motivated to plow on through. By the time Happy Hour started, we pretty much had the game working, but had some bugs to work out. We continued working on it for another hour and by the end we were having just this one small precise problem with our winning logic. It was having trouble with vertical columns, so we kept changing it and testing just the column, rinse repeat, and got really frustrated that it wasn’t doing what it should have been. Finally I was like, “Okay, let’s try this one last edit and then if this doesn’t work I’m just going to Happy Hour.” We ran it and as I hit the last key of the column and it acted the way it should we both cried out and hugged each other. It was an exhilarating moment, and there was no way that I would have gotten anywhere near completing it in that time if it weren’t for Shindo.

.@n_strzel and I broke a record today at @GA_SF. Finished the tic-tac-toe game in 2 hours. We’re celebrating!
— Amy MacKinnon (@ThatAmyMac) September 28, 2013

We certainly wanted to make the game look nicer and more polished, but the point was that it worked, so we went out to celebrate. We excitedly told our instructor that we solved it, and he said, “Okay, now I want you to do this with it…” and it was something we had already done. We made it bulletproof, yo! All the cheese was gone by the time I joined the party, but breaking records was far more satisfying. I managed to get the last cup of white wine and excitedly socialized with my classmates. While talking to some of the Camels it ended up turning out that another classmate had finished the Tic Tac Toe game before we did, but he was really quiet about it. However, that classmate has a Computer Science degree. So while we may only actually be 2nd best, we’re still the first beginners to solve it that quickly, so I’m still proud!

Thoughts and Reflections

After waiting so long to be able to do this, I can’t believe that the first week is already over. We have 11 more weeks to go, and it may seem like a long time, but I think they’ll go by quickly. By the end of the week I was exhausted, but I was able to easily get out of bed every day because I had something to look forward to, and every morning I woke up immediately wanting to get back on my computer and make my code better.

I am solving problems faster than I was at the beginning of the week.
I already feel much more solid, as a programmer, than I did at the beginning of the week.
My husband is probably already tired of hearing me enthusiastically talk about new Ruby methods that I learned that day.
I’m really glad that this is the bootcamp that I ended up in, and not the others I applied to, for numerous reasons.
When given access to unlimited coffee, I will drink it all.
I’ve made some friends and had great discussions with them.
I’m happier than I’ve ever been in my life.

I can’t wait to see what next week will bring.

WDI Week Two

2013-10-06T00:43:16Z

I made it onto the props board!

Monday

The entire morning was a lecture about the way the internet works. Things like:

HTTP
Servers vs. Clients
Ports
SSL/TSL
Data Persistence
and more!

I was familiar with about half of what we went over, but it was a whole lot of information to try to absorb and I think my eyes were probably glazing over at points. We then started learning about HTTP methods: Get, Post, Put/Update, Delete. I was familiar with these from working with AJAX and doing the Parse API tutorial on Codecademy, not to mention first encountering these terms with my first rails app. We started to learn how to use Sinatra and put these methods to use. I was excited about finally getting a chance to put some back-end and front-end together. We started out with just a basic calculator, putting in the parameters through the address bar and having the answer appear on the page.

For homework we had to use Sinatra to make a guestbook, where you enter the message parameter through the address bar, and one page thanks you for the message, and displays it, while another page shows all the messages. We also started adding in CSS to our workflow on this day, and basically if you let me loose with CSS I will work on it indefinitely. I’m trying to get better about being able to walk away from my art instead of perfecting it and never finishing.

Tuesday

We started learning testing, and got an intro to Rspec. We did a lab where we had to calculator scores for bowling, and so we’d write the test first and then write the code that would make our tests pass. Unfortunately I didn’t know anything about bowling scores so it was impossible for me to write the code without first understanding bowling. So I spent about 45 minutes just researching that and trying to get a grasp on the way it’s scored, and then was able to make one test pass. I didn’t get any further than that since I spent the majority of the time trying to figure out bowling. But now I understand what the term “test driven development” means. My initial intro to testing, through Learn Ruby the Hard Way, didn’t use Rspec, it used the built in testing, and we wrote the code before we tried to test it. I definitely need to study up more on Rspec though, as we haven’t spent a lot of time on it yet.

We did some HTML and CSS review, and did a lab where we had to make a one-page portfolio site for Cookie Monster. I busted it out in about 10 minutes and then sat there kind of bored while the lab continued for at least another 30 minutes. I had to remind myself that most classmates have not worked with HTML as long as I have. So I took the opportunity to review some of the other stuff we were learning.

We worked with Sinatra some more, and HTML forms, and actually started using Sinatra in a more natural way, so I liked it a lot more than on Monday. We got deeper into what REST is, worked on some more Sinatra labs. Then for homework we started working with our first API! That was also really exciting. We used the yahoo finance gem, and the assignment was to create a Sinatra app that had two pages: one with a search bar where you’d enter a stock symbol and then the page that shows the result. Here’s what the front-end of mine looked like:

Simple app, but we have to start somewhere! I also did very minimal CSS on it, because it was Jesse’s birthday and I was taking him to see 1776 at A.C.T. so I only had an hour in between school and the show to try to get the homework done. I got a pretty good start on it before I had to leave, and then I was frantically trying to finish when we were on the BART home. By the time we got home I had all the functionality working but hadn’t added in the styling yet, so I just threw in some quick CSS when we got home, and went to bed.

Wednesday

I was dead after being up so late the night before, and treated myself to coffee shop coffee. One of my instructors actually commented on the minimal CSS styling when I turned in my homework, and I told her that I just didn’t have much time to work on it. She said that she just figured that I didn’t care as much about front-end because my back-end was really solid and then it was just the little CSS. I laughed and told her that my background is actually in front-end, but I figured in this case, the bare minimum would have to do.

We started working with JavaScript and I was really excited because of my prior experience with JavaScript, and my continuing goal to become really awesome with it. We started doing DOM manipulation with JavaScript right away, which made me happy since that’s something that is really lacking in online tutorials. We worked with events happening when buttons are pushed, and did some setTimeout() and setInterval() fun things, which I had luckily gotten intimately familiar with those when I was doing the chat builder app.

We also went over recursion, which I mistakenly thought that I understood before the program started. One of our instructors did this ‘rabbit hole’ example that blew my mind. I had to continuing thinking about it for a while, but I think I get it now. We also started working with advanced CSS, which again, I was already familiar with, but I didn’t mind having a mentally easy day with being so tired from the night before.

Homework was to use JavaScript to create a bank page where you could deposit money into a checking and savings account and also withdrawal it from those accounts, and there was all this other criteria we had to complete, ending with: there had to be overdraft protection. I worked on it step by step, and got it all working. The html had already been provided for us, and we just had to do the JavaScript for it, but I ended up changing up the default CSS quite a bit because it was pretty ugly. This was the result:

Thursday

We were given a lab project to work on the entire day, and it was the largest scale of anything we’ve had to do so far. We had to combine Sinatra, Ruby, API’s, HTML forms, JavaScript, and CSS to make a movie search app. We were using the omdb API because it wasn’t going to need authentication. I found it a little limiting but understand why it was used for the lab. I had a couple of frustrations while working on it, one minor, one larger.

For the first one I had simply forgotten the first way we were using Sinatra, with entering parameters through the address bar. The 2nd frustration happened after lunch when I was working on the JavaScript disclosure widget, that was part of the lab’s requirements. I spent 2 hours wondering why my code wouldn’t work, suspected that it wasn’t even loading, wasn’t sure why, and I was so exhausted and fed up I said, “Fuck it,” took the JS out and sat there in a stupor for about 20 minutes. I was going to ask for help but none of the instructors were around the last hour that I was beating my head against a wall.

Finally an instructor came and took a look at my JS and it turned out that I had written document.getElementByID instead of document.getElementById. That single uppercase letter caused me a 2 hour headache. I couldn’t believe it. The bright side is, that my solution to creating a disclosure widget was correct and worked immediately once I fixed that. I was rather excited, because I’ve been wanting to do disclosure widgets for years, and so far hadn’t gotten any to work with just CSS. I deployed my movie-search app to Heroku, to show to a couple of people, but the images won’t work on it, so here’s a screenshot of what it looks like when I run it locally:

Movie Search Details Page

Jesse says he likes the UI better than IMDb, so I’m thinking about finding a better API to access IMDb with and create a movie search app just for my husband to use, because I love him.

My new Rubber Duck for debugging assistance!

GA bought a bunch of Rubber Ducks and right after lunch let us pick out our own to use for Rubber Duck Debugging. I chose one that had blue flowers on it. I have yet to name my duck though. Since we were completely immersed in the lab all day, and since GA was having a social gathering for us after class, they assigned “easy” homework for us of doing a sort-of book report where we had to find a controversial tech article, summarize it, state people’s opposing viewpoints, and then state our own opinion. I didn’t actually find the assignment easy and would have rather coded. The social gathering after class was fun though. We went across the street to a bar called Zeke’s and they stuffed us full of beer while we all chatted about nerdy things. I ducked out before everyone else so that I’d have time to do the homework and because I was dead tired. I got home at 8pm and didn’t finish the homework until 10pm and then went to bed. I would have posted the report on the blog if I thought the article that I assessed was worthwhile but I don’t feel it needs any attention.

Friday

We went over homework, except of course this time it was just hearing other people’s opinions concerning the book reports. I was glad that I wasn’t randomly called on, since I had trouble finding a decent article on Hacker News to talk about, and I didn’t have any recent articles saved in my Instapaper that would suffice, so I ended up just settling on one, because it was late, and I was tired and wanted to go to bed.

After that, one of the instructors went over JavaScript prototypes and inheritance. This was something I had already learned back when I first started learning JavaScript, and it wasn’t something that I had problems with at the time I learned it, but the way the instructor explained it and did the examples made me really confused. When we started the exercise after the explanation, I was so lost I pulled up the JavaScript track on Codeacademy to review what I had learned the first time around. I learned JavaScript from quite a few different sources, but I knew I could find the examples I was looking for quickly on Codecademy. After reviewing prototypes there, I once again felt like I had a grasp on things and understood it fully, and knocked out a bunch of prototype examples.

I then went back to troubleshooting why my Sinatra app that I had deployed to Heroku first thing that morning wasn’t working, until lunch. GA fed us pizza for lunch, which was pretty awesome of them, and a couple GA alumni talked to us about their experiences and gave us some advice. It reminded me that I haven’t really thought a lot about projects, and honestly am kind of terrified of coming up with my own ideas. This weekend I plan on brainstorming and doing some initial research.

After lunch they spent a couple hours going through how to do the movie app step by step, for those that were having difficulties. Since I already had gotten mine working, and felt like I have a pretty good grasp on Sinatra, I didn’t code along, but kept an ear open for explanations of anything that I wanted more details about. While listening I spent quite a bit of time trying to figure out how to deploy a Sinatra app with my own web host (Bluehost) since I wanted more control than Heroku provides, and as I suspected it’s quite a pain in the ass. I purposely only renewed my service for 3 months instead of a year because I thought there might be better hosting services for the web apps that I would be making in the future, and now I just need to find them. Bluehost was/is great for the simple hosting needs I had up until now, but it’s time to ramp things up!

GA Happy Hour getting started

When the day was almost over, they split the Snakes and the Camels into two groups again, for those that wanted more JavaScript review, and those who wanted to get a head start on the homework. Even though I didn’t yet know what the homework was going to be, I chose the latter group, because I figured it was unlikely to be anything more complicated than the JavaScript that I’ve learned in the past. The homework problems weren’t too hard, but I had trouble concentrating because the room we were in was very loud and disruptive. I still managed to get about 75% of the problems done before Happy Hour started though, so I am excited it’s going to be an easy homework weekend. I had a couple glasses of wine and chatted with my classmates for an hour before heading home to a home-cooked meal by my wonderful husband. I plan on spending Saturday reviewing all the topics that we learned this week and doing some extra study. Then I plan on forcing myself to relax for the whole day on Sunday to help my body and mental state.

Thoughts and Reflections

I was feeling really burned out the last couple days of the week. I think I haven’t been getting enough quiet time to myself for re-energizing. Textmate is perpetually open on my computer these days. I still don’t like SublimeText, no matter how many times I’ve tried to use it. I think I’m up to the 5th time this year of making the attempt.

I had planned on someday learning how to use Vim, because I’ve heard that a lot of Ruby developers use it in the workplace. When I queried one of my instructors about whether it would be really beneficial to know how to use it by the time the program ended, they exclaimed, “Oh I’d hire you instantly, just for that.” So that really reinforced it as a goal for me, to start learning it and to get efficient with it by December.

As of this week, I’ve finally stopped feeling like I’m not cut out to do back-end programming. I’ve had my doubts up until the program started, and kept thinking that I’ll have front-end development to fall back on if it turns out I really do suck at back-end. I’m overwhelmed by how much there is still to learn, but I really do feel like I can do this, and that’s an amazing feeling. Jesse’s been raving about me, about how talented I am, and how proud he is of me, and a lot of classmates have commented about how good I am, and I keep saying, “No, I’m not, I am just studying hard,” and other such excuses.

I don’t think it really occurred to me until today how much I’m still letting impostor syndrome kick in. Every time someone compliments me about my code, or my designs, I immediately downplay it, or give excuses as to why it’s really not that great, or I say, “Yeah, but I didn’t do this thing that I should have done.” I’m going to try to be more mindful about this going forward.

Wish I had time to post more code here, but there’s so much I want to review this weekend. Still happy, still exhausted, life is grand.

Computer Science in JavaScript: Merge Sort

2013-10-06T15:52:54Z

This blog post from Nicholas Zakas is the best explanation I’ve seen online for doing a merge sort in JavaScript. Most of the other posts I looked at give you code, but don’t talk you through it. I knew there was a reason I buy his books!

Computer science in JavaScript: Merge sort | NCZOnline.

WDI Week Three

2013-10-12T23:52:38Z

It really does feel like these weeks are just blowing by so quickly. Over the weekend I stumbled across some shortcuts in TextMate that I didn’t realize existed and made me love the software even more. The first couple days of the week were very mini-project based, which was nice. I said to my husband Tuesday night, “I’ve made 3 basic web apps this week…and it’s only Tuesday.” It’s really nice to have things like that to show the progress we’re making. First business of the week was that they mixed up the Camels and the Snakes, because when they polled us they found that we wanted more interaction with the other students. So I had to switch into the Camel classroom, which I like a lot better because there’s no glare on my glossy computer screen causing me extreme difficulty all day.

Monday — jQuery Review and AJAX

We went over homework and it turned out that I had completely misunderstood one of the requirements, so I tried to fix it while we were going over homework, but didn’t get to finish. We played around with jQuery some more and I tried, once again, to get this basic jQuery animation working that I started last May. It frustratingly still wasn’t working, and my instructor couldn’t figure out why either. I think there are definitely some issues involving event handlers for .keypress, since the same exact thing worked with clicking a button, but not with pressing keys. Way to go Codecademy for teaching things that don’t actually work when you’re not using your setup.

In the afternoon we started learning AJAX. Yay! I was looking forward to formal training on it, even though I’ve read the AJAX documentation extensively when I was building the chatbuilder app. During the AJAX lab we had to rebuild the movie search app using only jQuery/JS and AJAX. I was exciting about this since it means I would be able to host it on my site easily instead of using Heroku. During the lab I worked ahead while the instructor answered questions, so I ended up getting the app done sooner. I threw on the CSS from the other movie app, and voila. The one different thing though, is that the requirements for this project was that we had to do everything on one page, rather than having separate pages like we did in the first one. So when someone would click on the link for more info, it had to display the details while hiding the previous items. I really didn’t like this, but I understood why they wanted us to do it that way.

When I did the jQuery tutorials on Code School, they taught event delegation and I understood it, but whenever our instructor talks about it in class I just can’t figure out why it’s any different than the code that I’ve been writing. I think it’s something I really need to look into more extensively to fully comprehend it.

Homework that night was somewhat optional. They said if you were still working on your movie app, to finish that, otherwise to do the jQuery tic-tac-toe homework. They already had the html set up for us, and we were just supposed to edit the JavaScript file. They had the outlines of functions, but not the insides, and I couldn’t make heads or tails of how they wanted us to use those functions. I thought, “This would be so much easier if they just let us do it from scratch.” I really wish I had done it from scratch because I wasted so much time trying to figure it out. After an hour of writing code I realized wasn’t going to work, I started over and tried to ignore some of their functions, and that wasn’t really going anywhere either. Then I saw the instructors post in hipchat that we didn’t have to finish the tic-tac-toe and there would be time to work on it in the morning. So I called it a night.

Tuesday — JavaScript and Ruby review

In the morning we were going to be doing review. Those who wanted to review Ruby went to one classroom, and those wanting to review JavaScript went to the other. I went to the JavaScript review, but they didn’t really go over anything I wasn’t already comfortable with, so I continued working on the Tic-Tac-Toe whenever I had a spare minute, and also worked on my movie app some more.

The night prior I was reading my jQuery Compressed book on the bus ride home, read about Modals and decided that this was the just the thing needed for the one-page JS movie app. It made viewing the movie details much cleaner and easier to go back to the results list and select something else since it basically pops up a div in front of everything else and then you just close that div to see the page underneath again. Here’s a video of how it looks:

Your browser does not support the video tag.

In the afternoon we had the option of doing the Ruby review or starting on a lab project. Most of us who were in the JS review opted for the lab project. We had to create a To-Do List app using jQuery and as usual there a set checklist of things we were supposed to do. I got the beginning of mine set up pretty quickly but then hit a huge stumbling block that prevented me from going any further. I couldn’t get the checkbox to recognize the event handler for it. I tried a few different things, and then asked for help. Both instructors who looked at it couldn’t figure out why it wasn’t registering the event.

Unfortunately I couldn’t do anything else on the checklist until this problem was solved, so after about 45 minutes of frustration and getting worn out I said, “I give up,” and put my head down. But of course I wasn’t able to actually give up. My mind just won’t let things rest until I can figure it out. I looked at some examples of other jQuery code involving checkboxes and tried moving my event function to be within another function, instead of on its own, and magically it started working just the way it was supposed to. I’m not completely sure as to the why. Definitely a moment illustrated perfect in this picture:

After that it was smooth sailing. Here is what mine looked like: To-Do Project.

Homework was to just finish working on the projects, so I continued working on the Tic-Tac-Toe and finally got it working with their suggested functions. I extremely regret not writing it from scratch, and in the future will probably follow my instincts instead.

Wednesday — SQL

When they told us Wednesday morning that we were going to learn SQL I think I clapped with glee. It’s a subject that I hadn’t started to learn yet, but of course am anxious to learn because databases are so important. They explained the basic concepts to us while white-boarding out examples, and then they had us fire up sqlite3 in the command line. We then practiced creating tables, adding entries, editing entries, deleting entries, and of course querying the database. I was surprised at how intuitive and non-scary it was. We practiced a lot and then did a lab where we had to take the guestbook homework from Week 2 and turn it into a RESTful app that saves the entries to a database and then queries the database for the messages. It was pretty great to start having persistent data.

For homework, we had to create a Sinatra app called “Book Haikus” that uses a sqlite3 database. I ended up going to the USS Loma Prieta meeting that night, which I hadn’t initially planned on attending, due to homework etc, but my husband lured me to the Mission with Irish food, and it made sense to just head over to the Captain’s house for the meeting. I worked on the homework the entire time I was there but it was slightly slow-going due to the distractions. I managed to get all the functionality working by the end up the meeting (9pm) but still needed to style it. The requirements for the homework stated that we either had to incorporate the Google Books API or make the page super styling, so on the BART ride home I got to work on the CSS. I ended up staying up until 11:30pm trying to get it looking nice but wasn’t completely happy with it, and it was too late to try out the Google Books API, so I went to bed. I didn’t get the CSS decent enough until the next morning. Here was the final outcome:

Thursday — Rails

I showed off my page when we reviewed homework because no one else volunteered, and one of the instructors really liked it, so that made me feel better about it. She also rather enjoyed my haiku for The Mists of Avalon ^_^

We started learning drum roll Rails. Of course, I’ve made a Rails app before, but do I know Rails? Nope. So I’m pretty excited to learn it properly now. The morning was very slow going though. The instructor explained the concepts behind an MVC (Model-View-Controller) framework and then we started a live code-a-long to introduce a Rails project to us. Lots of people were having problems with the project set up, and others had questions each step of the way. It’s definitely one of the days that I’ve taken the most notes. I didn’t want to miss anything, and fully understand everything. Our project was called “Kittenz” because who doesn’t like cats*?

We were walked through creating a model, then a controller, adding views, editing the routes. There was a lot of focus on the database and how much easier it was to interact with the database in Rails. Over lunch I continued playing Rails for Zombies on code school to enhance my understanding and it was a great secondary resource in understanding everything we were doing with the instructors. In the afternoon we learned about validations (which I had just seen in Rails for Zombies) and then for a lab we had to try and do the same things we did in the morning, but on our own, by creating a Dog model and a Dogs controller, etc. I completed that and then adventured into creating a form to add an entry to the database, instead of adding directly from the rails console, like we’d been doing all day. I managed to do that, but decided to hold off on attempted updating or deleting until the instructors were gonna show us.

After that I started working a little on the homework which had just been assigned, as it was the end of the day. Just like last week, it was supposed to be “easy” homework of finding an article about failure (and lessons learned), summarizing the article, and then writing about what failure means to us, etc. I find these kinds of assignments very difficult, so it’s a good thing I went home to work on it and rest, instead of going to the multiple friend events I was originally planning on. In the end, it took me 3 hours, and I didn’t actually finish until 5 minutes before class started. I was still 50 words short.

*A lot of people but we’ll pretend like they don’t exist.

Friday — More Rails

The first hour or so of class was a “fireside” chat—complete with virtual fireplace playing on the projector—about failure and success. We sat in a circle and some people talked about their articles, and we all discussed what failure means to us, in regards to the program, and what success would look like. After that, the instructors informed us that there was a very important reason we had this kind of assignment and discussion, and that’s because Friday was going to be an all day lab day of having to create a Rails project on our own, and that we might feel overwhelmed with failure.

First they went over how to add things to the database from a form, in a Rails app, which I had already done the prior afternoon so I got started on the lab early. It was actually a very basic assignment, with a set list of instructions, so it’s not like we were just free to create anything we wanted. We were supposed to create something like bit.ly called rit.ly. We had to take the link inputted, store it in the database along with a hash code we created, and then display the code to them and have their new rit.ly link redirect to the original website when they’d click on it, etc. I had the entire functionality of it working by lunch time. So then after work I concentrated on the CSS and making it all look nice. I added in error handling, and then was kind of bored, so I added in iframe previews of the websites just for the hell of it:

After that I really wasn’t sure what to do next, with the limitations of the lab instructions, so I put on my headphones and continued watching Rails for Zombies tutorials. We had a brief break to meet Brooke, the staff member in charge of what happens after we graduate WDI. She’s going to talk more about the resources available to us when we get a little further into the course. Class ended a little early because we all had to be out of there by 5pm, since General Assembly was hosting a Geek Girl Dinner that night. So happy hour was taking place at Zeke’s, a bar across the street, and I went over with the rest of the group to socialize and drink some beer.

I didn’t find out what the homework was until late that night, and it turns out we have to take our Sinatra movie search app, and turn it into a Rails app, and then add on a reviews feature. I’m kind of excited we get to keep working with the movie search app, since I’m going to need a final one to present to my husband, for his movie searching needs, and it’s a 3-day weekend, so hopefully I’ll also get to study and review all the things I’ve been wanting to brush up on.

Thoughts and Reflections

I was having really intense anxiety on Monday, to the point of hyperventilating and tears. I’ve been really demanding of myself and it’s starting to take its toll. I know I need to learn to relax and stop thinking I can just study and work constantly, with no breaks. We’ve instituted a new rule at home that I’m not allowed to be on my computer or iPad for at least 30 minutes before bedtime and I’m not allowed to think about code, or read any coding books in that time. This has been a lot easier said than done, but I finally started reading Sandman to try and distract myself.

It’s really interesting to me that though I was studying JavaScript and jQuery a very long time before I had ever seen Ruby, I’ve had the most frustrations in the program with the former.
I’m really tired all the time again. My enthusiasm and excitement isn’t enough to sustain me anymore. Sometimes the only thing that gets me out of bed in the morning is the desire to finish perfecting my homework before class.
Overall, I felt that the instructors and the curriculum really prepared us well for Rails. It all feels very natural, because it’s all the same stuff we’ve been doing for a couple weeks now: Sinatra, accessing params, REST, SQL, erb. For all of it I was like, “Oh, so like what we’ve been doing.” It connects up so beautifully.
I’m still shy about trying to pair program. I think I need to push myself to do it once a week to break out of my comfort zone.

WDI Week Four

2013-10-21T02:21:46Z

We’ve started our first projects, so this will be a shorter summary than usual. Also, we only had a 4-day week due to Bartolomé Day, so I spent a good portion of Monday making my homework better and better and trying to study up on stuff.

Tuesday — Field Trip and Wasted Time

We went over the movie search rails app, and I showed mine off. Everyone liked the jQuery plugin I used for the star radio buttons:

We had a substitute teacher working with us all day, who teaches at the LA General Assembly, because 2 of our instructors were going to be out for a couple days. I wasn’t happy with the substitute and felt like Tuesday was a lost day due to us spending 3 hours just watching him get error after error and not actually teaching us how to do anything. It also didn’t help that he made a sexist remark towards me off the bat and I felt uncomfortable the rest of the day.

One highlight of the day, however, was our field trip to Yammer. I found the field trip to be just what I needed to relieve my anxiety. After hearing the engineers there talk to us, I stopped feeling overwhelmed. I’ve been stressing out about not having enough time to learn every minuscule detail about the languages, frameworks, and tools that we’re using. But the engineers stressed to us that you don’t have to know every detail of everything, you just need to know how to solve the problem when you come to it. I’ve heard this before of course, but the reminder was needed. I found everything they told us to be really motivating and inspiring.

Luckily the only homework we had that night was reading about Rspec. I would have been very upset if we had homework on the stuff that we didn’t learn from the substitute.

Wednesday — Associations, Rspec, and Bootstrap

Our regular instructor, Jackie, explained database associations to us very quickly, which was a relief after watching the substitute bumble it the day before. We also got our introduction to TDD (test-driven development) and worked with Rspec to test everything before coding it.

We got an introduction to Bootstrap and got to play with it for a little while. I have prior experience with Bootstrap, but hadn’t used version 3 yet. Previously I was not a fan of it but I’m warming up to it; mainly because of my love of responsive design and how much more time it takes for me to perfect my own media queries.

Homework included trying to do more tests on our own with the practice app we did in class, adding more models and controllers for the associations, and experimenting with bootstrap. I spent most of my time brainstorming for the upcoming project.

Thursday — Form Helpers and Partials

We spent the day learning about the built-in form helpers that Rails provides. At first I was very frightened of the form helpers because when I looked over them in the Rails Docs they looked like gobbledy-gook, and I thought “Why would I want to write forms a different way when I already know how to do it in html?” I have since changed my mind though, after working with them most of that day I now see why they’re super handy and efficient in a Rails environment. Also, you’re still able to use HTML5 form elements in them, which was one of my initial concerns.

We also learned how to make partials to use in our layouts and views. I had already used partials before with my first Rails project, but didn’t remember how. Turns out it’s super easy, so that took about one minute to re-learn.

Homework was to list out ideas for our first projects, what technologies we’d need for each one, and what the MVP (minimum viable product) would be. I had already written most of that down when I was brainstorming and preparing for project time. I really only had the 2 ideas, one of which I was convinced would be too complex for a first project. I’ve been stressed out for a long time about having to do the projects, because I’m not good at coming up with ideas. I’d rather someone give me their idea and then build it. So high anxiety right now.

Friday — Authorization, Cookies and Projects

Traffic was worse than usual because of the BART strike, so I was late to class. When I arrived everyone was in one classroom receiving a presentation. I am still not really sure quite what the presentation was for. They showed a Daily Show video at the end of it, and while I love The Daily Show, I wasn’t sure how the interview we watched was relevant to the course, unless the takeaway is that “knowledge is power.”

After the presentation we started learning about user authorizations and cookies. Coincidentally I had worn my “It’s all about the cookie” shirt that day. There was a lot to go over with sessions and authorization, but it was great to see how to implement all of it by hand, instead of just using the devise gem, which is what was used for my first rails project. We also learned about how to use the helpers for code we want to use in multiple places.

Then we were broken into groups to talk about our project ideas with each other, and the instructors gave a demo of some of the previous students’ first projects. By the end of class I still wasn’t quite sure which project I was going to do. Happy Hour started and I realized that I kind of hated having to talk about my ideas over and over again with different people. I was going to leave early but then ended up getting so involved with discussions that it got late and I accidentally had 3 glasses of wine. I started feeling horribly sick and laid on the floor of one of the classrooms for a little while, but then I almost fell asleep so I left to make the attempt to get home. It was a rough 1 1/2 hour journey home. I was worried I was going to get sick on the bus so I had my head down the whole time, and ended up missing my stop since they don’t announce the stops. Once I finally made it back I just collapsed in bed and my husband took care of me.

Saturday — Project

I decided to play it safe and make the beach finder app, which was the more “simpler” of the two ideas. It’s basically supposed to just aggregate information from other places so that you can go to just one site instead of 5 to help make a decision of which beach to spontaneously visit today. I got the Yelp API implemented right away, but then spent most of the day just being angry with it since it wasn’t going to do what I wanted.

Thoughts and Reflections

Today I hate everything about my project, think it’s an absolute mess, want to give up on it, and can’t stop thinking that I’m a horrible programmer. Also, I only have 4 more days to try to get at least some small part of it functioning and looking nice, and here the last 2 days have produced hardly anything, so I’m kind of a wreck. The whole week has just been really “blah” for me. I don’t know if it’s still a case of being burned out, or my increasing anxiety about the project, etc.

I really feel like there’s so much that I don’t know and that it’s preventing me from getting further in the project, and that I can’t take the time to try to learn what I need to know to implement things, because then I’ll run out of time. It’s very frustrating. I also know that I should cut myself some slack because this is the first time I’ve tried to create a rails project by myself with complete freedom of choice, and so of course it’s not going to be smooth sailing. I just can’t bear the thought of failing at this.

BestBeachToday Project

2013-10-28T03:30:55Z

Splash Page

The app that I first set out to create, and the one that I presented on Demo Day on Friday are different, because I really had to scale my vision down and just produce the MVP due to lack of time. I’d like to think of what I presented as a working prototype. I plan on making it lots better.

What I Set Out to Create

A quick and easy way for people to find out the best beach to go to for spontaneous beach trips. At a glance they can see a list of beaches nearby, the current drive time based on traffic, weather forecast, etc. It might sound lame, but I came up with the idea because I spent hours trying to come up with something that would be useful that didn’t exist already.

I tried to think about things that drove me nuts online, and I remembered that back when I had a lot more free time, I’d decide that I was going to spend a day at the beach, but when I’d get up in the morning to go, I’d end up spending over an hour just trying to figure out where to go. I’d have to go to 5 different websites to obtain driving information, weather forecasts, information about the beach itself, and if those didn’t satisfy me, starting the search over. By the time I was finished I’d often lose motivation to go at all. I wish I would have had an idea that wasn’t so frivolous, but as stated in last week’s blog entry, I’m not good at ideas.

So my vision included finding all the beaches within 50 miles, showing current traffic, showing weather information, having a more detailed description of the beaches when you clicked on them, as well as amenities and pictures. There was going to be tags to filter by, since everyone has a different opinion of what makes a beach “the best.”

I thought it’d be easy to just aggregate all this information into one place, but I learned a lot about API’s this week and the limitations of them. After 3 or 4 days of having to switch out API’s for different ones when one wouldn’t be good enough, I realized I was going to have to just produce the MVP.

First Obstacles

Trying to get the JavaScript variables created by the HTML5 Geolocation function into the controller - And then getting them into the controller but not being able to display results on the page
Not being able to get more than 20 results from Yelp
Yelp not having descriptions for businesses
Not being able to search for more than 25 miles away with Yelp
Yelp only providing these tiny images for the business picture
Yahoo weather information only providing limited data
Not getting any of my Rspec tests to run; not to PASS, but to RUN. I think somewhere in the set-up process there was a hiccup.

Solutions

Transferred the JavaScript variables through an AJAX call to my controller action. - And then when that worked, but I could only get everything to display in the rails console and not get the front-end to re-route and show the results, and once it re-routed it no longer had the variables. I abandoned AJAX and settled on having 2 form input fields that the HTML5 Geolocation would automatically enter the information into, and then the user would have to press the “submit” button, which then got everything flowing properly through the proper CRUD actions in the controller. Why didn’t I do this to begin with? I was trying to save my user from having to ever see the lat & lon and press a button.
Problem not fully solved, there was no other API that could give me the list of beaches I’d need, so I had to grumpily say “Oh well” for now and hope that users wouldn’t get mad that they didn’t have ALL the options
I looked into other API’s but couldn’t find anything that would give me the descriptions. I considered hand putting them into my database, but there wasn’t time and that wouldn’t be an ideal option since there are thousands of beaches in the world. In the end I filled the gap with the Yelp review excerpts. A temporary solution.
Again, problem not solved, and I had to just settle on having my users given only the “top” options within 25 miles, as deemed worthy by Yelp. I’m looking for other solutions.
I put the circular vignette on them to try and make them look nicer than these tiny pictures in a much larger container; another temporary solution.
I replaced the Yahoo Weather API with the Weather Underground API
I had to build my app without tests and I’m really unhappy about it, as I feel like this is definitely a project that would have benefited heavily from TDD. There wasn’t enough time though to trouble shoot why Rspec wasn’t working if I wanted to have something functioning by Friday. The venn diagram comes to mind that says you can only have 2 of these three things: good, fast, cheap.

Second Obstacles

Google Directions API only being able to show 10 results at a time
Google Directions API not having CURRENT TRAFFIC, only regular drive time without traffic.
Everyone in class getting blocked from using any kind of Google Maps API on a daily basis because we were all accessing it from the same IP address and they have a 2,500 per day rate limit
The Flickr API not allowing general queries for photos. Everything you do has to be in regards to your own photos, collections, groups, etc.
Weather Underground having an API rate limit of 10 calls per minute. - And then getting to the afternoon before Demo Day and realizing that only one person can use my site at a time and this would be a problem if my classmates tried to use it the next day

Solutions

For 1, 2, and 3, my solution was to just not use Google Maps. Since my MVP only needed current traffic time, and Google Maps didn’t provide that, it didn’t make any kind of sense to use their API. So I looked into a couple other options and ended up choosing the MapQuest API. I was an avid user of MapQuest for many years, and only stopped using them when they changed their UI to look more like Google Maps, which in their case, was not in their favor. I’m pleased to say that for what I needed, their API is vastly superior, and I knew no one else would be using it. So I implemented it and it was smooth sailing. - I do still think that Google Maps provides better overall directions, however, since they have such ease of use for bicyclists, pedestrians, and public transit, so instead of showing direction on my page with the Mapquest API, I just decided to provide a link to directions on Google Maps that already had the information filled in for the user. It’s kind of better that way, anyway, because it keeps the page uncluttered.
Much like with the directions link, I ended up providing a link to Flickr on the show pages that does the search for that beach for you, so that you can see pictures for it. This is a short-term solution. I plan to do something similar to what the Yahoo Weather app does, and start a group that people can add photos of beaches to, which can then be used as a gallery on the site.
I begrudgingly reduced the amount of beach results from Yelp to 9, assuming that the user would only have a chance to click on one of them within the same minute, so that wouldn’t go over the 10 calls a minute limit. This wasn’t an ideal solution though, because if they immediately hit the back button, it would call those 9 results again. - I realized that the way I had it set up really only allowed for one user at a time. If multiple people were on the site at the same time, it would instantly go over the API calls limit on Weather Underground. I thought long and hard about just removing the current temperature from the results page, but I knew that if I did that it would defeat the purpose of the entire app, because you wouldn’t be able to see the most important information at a glance. When I complained about my API limit on Twitter, one of my developer friends commented back, “Cache all the things!” I knew that wouldn’t completely solve my problem, because it would only work for people who were searching in the exact same area. Even if someone in SF was searching and someone in Oakland was searching, they were going to get different results. However, the more I thought about it, I realized that for Demo Day, all I needed was for my classmates to be able to access at the same time; I wasn’t going to mass advertise the link. So I set out the night before Demos to figure out how to cache the results page, and also the show pages, so that I wouldn’t have to worry so much about people accessing the site. It took me until 1am to fully implement it, but it worked. Another short-term solution.

Conclusion

The app still has a few bugs, but it’s functioning fairly well. I fixed a few before heading to school on Friday, and I’ve made sure to log all of them in my Trello project to continue to fix when I can. I didn’t get to style the pages as much as I wanted, since back-end was more important to get done. I also have a wishlist of items to make the site reach the completeness of my original vision. It ended up that I didn’t have to stay up half the night implementing caching, because not a single person accessed my site during the school day, courtesy of Google Analytics. But I suppose it’s not a total loss, because I was able to show it to a couple select friends on the weekend to start getting user feedback from people who are not me.

Honestly, I was very disappointed in the Demo Day process. I got stuck being one of the last people to go and they rushed through the last people so they could get to the celebrations early. I didn’t get to talk much about my app and it felt so anti-climactic after the constant work I put into it for over a week. I get more emotional when I’m really tired, and I sat there wanting to cry. It was a rough day for me and I went home to rest. I was so insecure about my project to begin with, and I think the underwhelming response confirmed my fears. But I plan to stick with it, because I find it useful, so maybe someone else will too. Also, I did learn a lot about using API’s and caching, so it was certainly worthwhile.

Short term plans to make it more usable:

Switch from using Yelp, to using Foursquare’s API. I actually can’t believe I didn’t think of this sooner, since I use Foursquare every day. Foursquare has categories and I checked out their API and they provide much better access than Yelp’s.
Find another weather API that allows for more calls per minute. I love Weather Underground, but I cannot afford to pay $150/month to get better access.
Refactoring! It’s kind of a mess right now because of the rush.

I wish I could provide the link to actually share the project with all of this background, but it would create the potential for me to go over my limit, so until I switch over the weather API the github link is all I can provide, but I will be sure to update this once I change the weather API, which is top priority.

WDI Week Six

2013-11-03T00:14:06Z

What we’ve “learned” in 6 weeks

We are now half way through the WDI program, which I have mixed feelings about. I definitely have been experiencing a slump and some depression after finishing Project 1.

Monday — Refactoring and Rspec refresher

We started out Monday with an instructor showing how she would refactor some of the code from one of our projects, and then we had to pair up and make notes for our partner of what we thought they could refactor in their project’s code. Then we were given time to actually go through our own projects and refactor our code. I was very excited about this because I have a lot that I want to clean up in my own project, and it’s definitely a work in progress.

We then had another Rspec refresher, which I was grateful for because it’s one of my weak areas, at least when trying to use it with Rails controllers, and then homework was that we had to write some tests for our projects, if we hadn’t already when we were building it. I had wanted to to test-driven development with my project, but I couldn’t get the tests to run, so I was really frustrated that I wasn’t going to be able to do the homework since that issue hadn’t been solved yet. Right as I was walking out the door a teacher was able to help me figure out that when I installed Rspec in my project, there were important things missing from the spec_helper.rb file that are supposed to be there automatically to tell it where to look for files.

So I finally could run tests in my project, but I spent hours trying to right a single successful test for things in my controller and couldn’t get anything to work.

Tuesday — AJAX in Rails, Unobtrusive JS, and JavaScript Testing

We had an AJAX refresher and how to use it in Rails to interact with the controller actions, and make a one-page To-Do List app. We also learned how to use unobtrusive JavaScript (a Rails convention), and put it all together with the AJAX to control everything. Then we went over Mocha for JavaScript testing. At the end of the day we were told to load Mocha into our projects and test any JavaScript we had, but I only had the one JavaScript function and couldn’t get Mocha to work.

I finally had a 1 on 1 with one of the teachers, after not having one in 3 weeks. It was really great to finally be able to address some of my questions, concerns, and subjects I was struggling with. It was the longest 1 on 1 that I’ve had and I felt really good afterwards. She helped with some of my Rspec issues, and I’m looking forward to actually getting to delve into it deeper when I have a chance.

For homework we had to do a one page Mad Libs site in Rails. It was basically the same thing we did in class with a To-Do list, but definitely hammered in what we learned by having to do it myself, even with having the previous code to refer to. Since I concentrated primarily on the back-end functionality and that took me a few hours, my madlibs were very uncreative. I was too tired to write out stories.

Wednesday — Underscore.js, Asset Pipeline, and JS Templates

After going over the homework we were introduced to a popular JavaScript library called Underscore.js that extends the functionality of JavaScript and makes it kind of more Ruby-like. We then went over the asset pipeline in Rails, and we very quickly watched one of our instructors talk about how to use Underscore.js’ JavaScript templates. Since we were just watching him go through it, and not actually coding it ourselves, a lot of people were confused and frustrated when we were told that we would have to use the JS templates in the homework.

The afternoon was spent taking a long assessment test so they could figure out how well everyone in the classes know subjects we’ve covered. Not all of the questions that were on the test were things we learned in class, which annoyed me slightly because while I do try to learn as much as I can outside of class, we’re left with very little time to do so. We also had to fill out the test in a Gist, and I really wish I would have used my text editor instead. We weren’t allowed to use any help though, no notes, or googling, or IRB, so I kind of felt like using a text editor would be cheating since sometimes they’ll fill in the syntax for you. The test covered Ruby, Rails, SQL, JavaScript, and jQuery.

Homework was creating a bucket list one-page app, using Underscore and JS templates. I had no idea what to do and wasn’t in a place that had internet, since I went to the Double Union Feminist Talks event that night. So I spent a couple hours just setting up my app the best I could, but didn’t actually finish. It was the first time in 6 weeks that I didn’t finish the homework. I was in such a great mood from the event that night though, being around like-minded people, that I didn’t feel too guilty about it.

Thursday — Halloween and Review

First thing we did was go over the long test we had taken the day prior, and we had to write our own scores down for each answer. Personally I don’t trust people to be honest, and to not change their answers, but I guess to be fair, this isn’t a normal kind of grading, it’s more for ourselves than anything. I certainly was glad to see where my weak areas might be. We also had some JavaScript review, which has become a pretty regular thing.

Since it was Halloween there were a lot of celebrations throughout the day, and I felt like we really didn’t do much that day in class, but I was okay with it, because it’s kind of hard to work on Halloween. We all ate a lot of candy, cupcakes, etc and there was a piñata. Not a lot of people dressed up, but we had a costume contest and I ended up winning Runner-Up. My classmate, Luke, won the contest with his Emperor Norton costume and I was okay with losing to that. Here’s some pictures of some of the costumes and festivities:

Homework was another “book” report but this time we had two options which made me so much happier because I figured it wouldn’t take me as long as it usually does. However when I tried to go to the website for the javascript library I was going to write about, it was completely down, giving a 403 error. I then spent about 2 hours trying to find something else to write about but starting falling asleep at my computer. So I gave up and watched The Thing with my husband to celebrate Halloween.

Friday — Ruby & JS Terms, jQuery review

The first half of the morning was taken up by reviewing Ruby and JavaScript terms, which felt painfully-long. The instructor was trying to get the class to shout out the definitions for one of the terms, and most people didn’t want to participate. I could have quickly done most of them, but I figured they didn’t want just one person to give all the definitions, so instead we sat there is mostly silence as they tried to drag the definitions out of people who didn’t want to participate. It seemed so wasteful of time. I really wish they would have just used our randomized people picker system to quickly get through it all.

During lunch I talked to one of the students from the last cohort, who just recently started an Apprenticeship program position through General Assembly. I started getting pretty nervous when she said that for their cohort there were only 3 apprenticeship positions available, and that other classmates were really struggling to find development jobs. I guess it only reinforces that I need to continue to work extra hard to make sure that I do not fail in my goals once the program ends.

We did a lab all afternoon and had to pair program. It was the first time in 6 weeks that we were instructed to genuinely pair program and I was glad for the mandate since I need practice doing so. I was very glad for the experience and while my partner and I experienced a few frustrations with the code, we kept progressing and got to a decent stopping point. I think I need to get better with self-control and etiquette while pair programming, because we were building the program on his laptop, and sometimes when I’d get really excited about what I thought would be a possible solution I’d practically steal the keyboard so I could type it out. I am also not as good at explaining my thoughts as I’d like to be.

Homework for the weekend was to finish working on the project that we pair programmed on.

Thoughts and Reflections

On Monday I had my first thoughts about dropping out of the course, but when I looked into doing so I realized it was too late to get any refunds, even a partial one. My reasons for wanting to drop out are opposite of the reasons a lot of people drop out. I won’t go into the reasons now, because I plan on writing a blog post about the course in general once the full 12 weeks are up.

Tests make me nervous, which is why I’m really nervous about job interviews. We had some questions on our assessment test this week that involved code that I’ve written a hundred times and have never had any problem remembering syntax. I wrote them wrong on the test. To be fair, the fact that I was writing it in a gist instead of a proper text editor kind of threw me off too, but regardless there is no reason I should have messed up such easy syntax. It makes me wonder if I’ll I be able to perform under pressure during job interviews.

I’m glad that the week ended with the pair programming high note, because other wise it was a pretty sucky week and I felt really apathetic for most of it.

Highlight of the 2013 Star Trek Con

2013-11-11T19:34:18Z

So THIS happened.

Us with Jonathan Frakes

I'm Alive

2013-12-20T21:53:45Z

There are two reasons that I stopped posting blog entries after the 6th week of WDI. The main reason is that I’ve simply been too busy. During the 7th week I was so busy on the 2nd project, which was a group project, and after that it just continued to stay busy; every spare minute I was either working on homework, projects, or studying. I even started to feel behind when I let myself go out a couple times. It’s no joke, you cannot try to have a social life while doing a bootcamp.

The 2nd, lesser, reason is that I have been in the process of transitioning my blog from a Wordpress format to Jekyll. I’m not finished doing so yet, but I’ve had little time to work on it since it’s not a priority compared to schoolwork. Since I had already exported my Wordpress posts and set them up with Jekyll I didn’t want to keep adding posts to Wordpress. It finally got to the point though that I decided I shouldn’t let this transition prevent me from writing.

So yesterday was the last day of class, and it’s bittersweet. It’s been a long, short 3 months. I’ve been living in this bubble and have emerged shocked to find out that it’s almost Christmas. I thought it was still October? I’m nervous about going back to the real world, but also excited at the adventures and opportunities that lie ahead. I have a lot of catching up to do on blogging and getting back in touch with my friends and relatives. My life is going to continue to be busy for the time being, but there’s less pressure now so I can start having my evenings and weekends back. Looking forward to sharing more of my experiences at General Assembly soon.

Arbitr Project

2014-01-07T02:17:05Z

Arbitr Splash page

The final project that I created in WDI was an app that had been on my mind for quite a few months because it was an app that my husband, Jesse, had been wanting someone to build since February 2013. He is an assistant debate coach and spends most of his weekends during the school year at Debate Tournaments. There is a particular way that both the judges and the teams track debate rounds and they are referred to as flows. A textbook shows an example of a flow as this:

An example of a flow

When in reality they end up looking more like this in the heat of the round:

A handwritten example flow

So Jesse had looked extensively to find a better tool for flowing a debate round. Some people tried to use Excel, but most people just settled on handwriting everything. Being unable to find any kind of software or tool that was ideal for the situation, Jesse decided that someone needed to build an app for this and he knew that if effective, it would become a popular tool.

I thought about creating the app for him for the first WDI project, but mistakenly thought it would be way too easy to build and therefore wouldn’t be a good project during the program. By the time the final project rolled around I knew enough to know that the app would be far more complicated than I had originally anticipated, which made it a great final project. We were also lucky enough to have 2 weeks to do our final project, instead of just the single week we had with the previous two.

Project Planning

I spent the entire first weekend project planning. I had already been compiling ideas, and had a good idea of what technologies I was going to need. I planned on using Backbone.js even though I had struggled with it the week we learned it in class, because I knew the app would be so client-side heavy and need to be really responsive to user input and actions. One of the reasons I had struggled with it in class was because we learned it in CoffeeScript, and I wasn’t comfortable with CoffeeScript at all, and often only understood what was going on when I looked at the compiled JavaScript versions. So I was very conflicted as I was about to start this project. Did I want to re-learn Backbone.js in vanilla JavaScript and probably understand it better? Or did I want to struggle and try to learn it again using CoffeeScript? I ended up deciding to push through and continue with CoffeeScript. I was very worried that I would regret this, but luckily this awesome site saved me whenever I couldn’t figure out exactly how to write something in CoffeeScript.

I also was initially conflicted on what I was going to use as the back-end. Of course Rails would be a natural choice because everything was so Rails focused in the program, but I was highly considering Node.js as a better option, or possibly not having my own back-end at all and interfacing with a Parse cloud database instead. I wanted to use the best tools for the job instead of just settling on what I already knew, but after discussing it with an instructor it became clear that Rails would be the best option for the time being, since it could possibly take me the entire 2 weeks to get comfortable with Node.js, and with Parse I wouldn’t have any work to show for the back-end.

During the weekend of planning, I hit a huge bump with the data modeling. After discussing with Jesse more of the details surround the Debate events and what kind of interactions the site would need, I spent an entire day just working through how to do the database schema and object models, and at one point worried I would have to abandon the project because it’d be too complicated. After many pages of writing as I worked through it I realized I had been thinking about it the wrong way and came out with something much simpler than I thought it’d be.

Data Modeling

Project Week 1

With the initial planning stage over I was ready to start fresh on Monday morning with setting up the Rails project, and starting on the Rspec tests as I built out my models. That went pretty quickly since it was all things I had already done many times before, but then came the hard part of starting to set up the Backbone framework on top of Rails and start building it out. I found these Railscasts very helpful in the initial set up, especially since it was in CoffeeScript, but I later ran into problems when trying to follow it too literally and had to branch off to do things my own way.

The first few days with Backbone were pretty rough. It wasn’t necessarily Backbone itself that was so difficult, though of course I was still learning it so extra time was involved in that, but getting Backbone to talk back and forth with Rails took up a lot of initial time and I ended up queueing myself for help from the instructors at least once every hour. Those first couple days I was only concentrating on getting the user accounts and sessions set up with Backbone and had to figure out the best way to pass variables to the front-end so that the page would recognize whether there was a current user or not and act accordingly. I ended up going with the Gon gem for that, though I continued to have problems with finding the right place in the Rails controllers to set it so that it knows to update itself when things change.

After the first two days of actual coding all I had was the back-end set up for users and sessions and just enough Backbone set up on the front-end to log in and out of the app and set up new users. I felt like progress was going too slowly but those first couple days struggling with getting Rails and Backbone to work together were so important to the learning process and I had a lot fewer issues after that because I was getting into the swing of things and was able to concentrate more fully on Backbone. One big problem I had though, that was related to Backbone, is that I couldn’t get the Routers to work successfully unless it was all in the same Router. An instructor advised against using the built in Routers and pushed me towards using Page.js, which ended up being pretty user-friendly and has worked pretty decently.

I had 3 main parts I needed to create and each one went one level deeper under the other so I started at the top level, working on setting up Tournaments in Backbone, which was one of the easier parts: allow people to add a tournament and it would display in a list.

The biggest challenge I ran into on this part was getting the tournament list to sort by tournament date instead of tournament id. This is something that would normally be very easy if you’re just doing it in Ruby, but since Backbone has its own collections that it refreshes on a regular basis, it’s a little trickier…or so I thought. I kept trying to use .sortBy after the collection is fetched but was having no luck getting it to reflect the way I wanted it to sort. It turns out that Backbone actually has a built in property that makes it easy peazy to automatically sort a collection by whatever field you specify: the comparator property, which is ideal because whenever you add a new item to a collection it already knows that it needs to be sorted that way and inserts the item into the correct spot in the list.

class DebateJudge.Collections.Tournaments extends Backbone.Collection
  url: '/api/tournaments'
  model: DebateJudge.Models.Tournament
  comparator: 'date'

The next part to work on was Rounds to go beneath each of the Tournaments and that ended up taking up the last couple days of the week. The Rounds index underneath each of the tournaments included event categories: Lincoln Douglas, Parli, Public Forum, and Policy, and any time a round was created it needed to go under the correct event, so there were lots of collections involved.

One of the huge hurdles I crossed concerning rounds was problems with loading and refreshing data since it was doing it asynchronously. The DOM wouldn’t be loaded yet and my Backbone views would be trying to append data and HTML elements to other elements that didn’t exist yet. The real life saver with this was telling the Backbone views to specifically append to “this” view element that was going to be loaded. So it would append to that view’s element before it tried to load that view on that page. An example:

appendTournament: (tourney) =>
  rounds = new DebateJudge.Collections.Rounds @rounds.filter (round) =>
    (round.get 'tournament_id') == tourney.id
    view = new DebateJudge.Views.Tournament(model: tourney, collection: rounds)
    @$('#tournaments').append(view.render().el)

Since the #tournaments element refers to an element that lives inside the template of the view, the @ symbol (which refers to ‘this’ in CoffeeScript) solved the append issues. Another really great benefit of specifying to look for a DOM element within that Backbone view, as opposed to the entire DOM is that when you’re toggling an element by classname it will target only the one that was generated by that view instead of every element with that classname. This was very important since I have so many views that are being generated with the same classname, such as rounds, or contentions within the rounds, that need to be interacted with separately.

Project Week 2

The next part that I needed to work on was really the most important part and the beef of what the site was all about: the Round page where all the action would be taking place. Before I even started working on the contentions that would be within each Round, I had to create the view for a Round and the workspace that the contentions would eventually be in. I spend an entire day just working on the CSS that would be this page. I knew from before I even started working on the project what I had in mind for the Round workspace. I have not yet mastered drawing with my huge stylus on my iPad mini, so this was my original messy sketch:

All the events have a different amount of columns and at first I thought I was going to have to create a different template for each of the event categories, but luckily I realized before I started coding it that that would be too much duplicate work and was able to create just one view template that would be able to generate the different layouts for each of the events. Where the difficulty with the CSS came in is that I knew I needed a page that was going to be able to scroll horizontally to be able to accommodate a varying amount of columns, and that it couldn’t just wrap because the columns themselves would be varying heights and the user would need to be able to always compare one column with the next one. So I needed the page to scroll horizontally, and I needed each column to be a somewhat set height and have its own scroll bar so you wouldn’t have to worry about the page getting so long that the user would have to scroll up and down.

Having been a heavy-duty user of Trello for 2 years now, it ended up being a huge inspiration for me because their layout is extremely similar to the layout that I wanted to create for my app, but creating that kind of layout is not as easy as it might seem. You definitely need an excessive use of divs and I thought I could get away with having the bare minimum but alas, I had to appease the powers that be. After spending most of a day just working on perfecting the CSS for the layout I ended up actually forcing myself to say, “That’s good enough for now,” because I couldn’t get the bottom to be responsive, which is really important, but I needed to move on to other things because of the time constraints.

After that I had 3 days left before the project was due and started into high anxiety mode of needing to use the rest of my time as productively as possible. I still had to create the last piece of the puzzle: the contentions. All the individual little pieces of text that were really the most important aspect of the entire thing. Creating the contentions is their most basic form was not difficult because it’s the same idea I’d already been doing over and over—let the user create information and immediately add it to the page. The real work though was adding all the features to the contentions that would trump working it all out on paper.

One issue I ran into immediately was that there wasn’t a straightforward way of specifying in the automatic call to the API that I wanted only the contentions for a specific round. The best I could do at the time was get only the contentions for the current user, which means that a lot of unnecessary data is being loaded for each Round page and could very well get out of hand if the user uses the site enough. This obviously needs to be fixed and would probably just be a matter of passing a parameter to the API that it could use to filter the contentions, but since it didn’t interfere with the site working at the time, I pushed onwards.

After the day of getting the contentions to work in their most basic form I decided to do my initial deploy to Heroku in order to have time to troubleshoot any issues that arose in production, and that took the rest of the evening and the next morning. The first problem I had with the deploy to Heroku is one that I was familiar with because of the same problem with the group project I had done previously. The Rails helpers that are supposed to automatically find all the CSS & JS assets in the html header weren’t doing their job, so I had to manually go in and specify the files. With that fixed the second issue that stumped me was that some of the page was showing but not all of it. I figured there must be something weird about deploying a Backbone.js app to Heroku but when talking to a classmate who was also using Backbone.js she said that she didn’t have any issues, so I delved deeper. It turned out to be a simple case of having broken something that was previously working and not realizing I had broken it because I hadn’t looked back at it in a while.

After fixing those bugs I spent the rest of the day finessing the contentions. I made the contentions editable, deletable, and added in a label that could be toggled showing at a glance whether a contention had been refuted or not. I also added in the ability to delete rounds, if need be. There were tiny hiccups here and there for but for the most part that all went smoothly. I also realized that I should probably have some kind of splash page so spent the final part of the day rearranging some of the code in order to add a very basic page that I planned on fleshing out later.

On the final day of being able to work on the project I decided that I would only let myself work on additional features for the first half of the day and then concentrate on styling and bug fixing for the rest of the time. The two big features I had on my agenda were a timer and the ability for users to enter markdown into the contention fields. The timer was a feature requested by Jesse from Day 1 because teams keep their own time during a speech and signal each other if it’s about to run out. Six months prior to starting on the project I had planned on writing my own timer for it, but a classmate had come across a timer in October that was exactly what I needed, so I had already looked into that and played with it a little. I figured the timer would be quick and easy for that reason and that the Markdown feature would take up most of the morning, but it ended up being the other way around.

I had no problem getting the timer to work when I was playing with it in a simple html page and js file, but had to invoke the function in a different way in my Backbone app in order to get it to function properly. I also had to add in ways for the user to be able to set the time over and over, since the time for each speech in a round varies. It all ended up working out beautifully after the initial struggle.

The markdown was necessary because in basically all scenarios of debate judging the user is going to want the ability to use bullet points and separate paragraphs rather than having some large chunk of text that’s not easy to read at a glance. I was worried that it would be difficult to implement, but was fairly simple and took hardly any time. I had spent a lot of research time leading up to the last day figuring out the best markdown method to use and decided on Markdown.js. It was everything I wanted and easy to implement. Besides adding in the .js file, all I had to do was create this function to use on each contention as it gets rendered on the page:

applyMarkdown: (value) ->
  @$('.markdown').html(markdown.toHTML(value))

From there on out it was all bug-fixing and styling and showing it to Jesse when I got home that evening and then doing a ton more styling changes after getting his feedback. There was so much more that I wanted to do with it but the MVP to present to my class the next day was finished. I did my final push to Heroku and refused to let myself pick at it the next morning as we were waiting for presentations to start.

I spent my entire presentation time giving a tour of the app and talking about what it does, as well as explaining all the Debate stuff, and then ran out of time so I didn’t get to show any of my code to my classmates. The feedback was overwhelmingly positive, however, and I was surprised by it. I figured that this project would be the one that was least interesting because it’s such a niche thing, but it was my only project that people came up to tell me they liked, and I discovered a few people who used to be debaters in high school and/or college. It was a great way to end to the bootcamp.

What’s Next

I have a wishlist of features that I’m continuing to implement whenever I have a moment as well as a long list of bugs to fix. Here are some of the features I will be adding in the immediate future:

Offline Storage
- This is necessary because the teams don’t always have wifi at the location of the tournament. I plan on implementing HTML5 Local Storage features that will sync back up with the server whenever online.
Email for forgotten passwords
Visual link between contentions
- The user needs to not only be able to designate which contention refuted another contention, but a visual link needs to be made so this can be quickly determined. I plan on either using the HTML5 Canvas or D3.js to draw lines between the linked contentions.

I’m dedicated to this project and am excited that it’s going to get a lot of use very quickly as the debate season starts back up. Anyone interested in following along can find it on Github here.

Jekyll Conversion Complete

2014-01-22T20:03:00Z

I finally finished liberating my blog from Wordpress’ clutches a few days ago and getting it set up with Jekyll instead. It feels really great to have so much more control over it and to have it also be more lightweight.

After getting it set up with my current website design, I started preparing it for uploading and realized it didn’t make sense to keep the files separate from the main part of my website and decided to translate my webpages into the Jekyll format as well. This actually has also been such a relief organizationally because I’ve gotten spoiled by templates in all my web app work and can now set up templates easier for my own simple and static site. I still have a lot of work to do in fine-tuning it and adding features to the blog but it’s a nice start and I’m really excited to work on it more.

I’m also excited that I can more easily use whatever syntax highlighting stylesheets I want, so now I can force the Tomorrow Night theme on everyone else. I’d say that my only real complaint so far is that it publishes drafts even though it’s not supposed to, but that may actually have to do with the paginator feature and I could probably circumvent it by adding in a conditional that checks the YAML variable for published.

Day One with Ember

2014-01-25T20:26:00Z

I recently started giving myself a crash course in Ember.js to do a quick example app for a job interview. I was pretty sure I could pick it up quickly since once thing I definitely learned in the bootcamp was how to learn fast and work quickly. This certainly isn’t ideal for most real world situations because you want to produce high quality sites and apps which require proper planning, testing, and attention to detail. But it’s nice to know what I am capable of doing in a pinch.

One of the things that is really starting to amaze me is that the more I learn about all these different technologies the less scary everything looks, as a whole. When I look at new languages, they don’t look like Greek and I can generally get the gist of what they’re doing. It’s also the same with JavaScript frameworks, though I’m really only on my 2nd right now. After about 8 hours of working with Ember.js it reminds me so much of Rails with its naming conventions and automated “magic.” I can see how Backbone.js gives you so much more liberty, which is nice, but Ember.js makes specific things quicker and easier because of the conventions. An example is when you’re looping over a collection in its template, you don’t have to specify the variables for what you’re looping over because it knows that you’re probably going to want to loop over the collection of objects that are associated with that template and controller.

You could write this:

{% raw %}
  {{#each user in users}}
    <h1>{{user.name}}</h1>
  {{/each}}
{% endraw %}

But Ember will let you write this instead:

{% raw %}
  {{#each}}
    <h1>{{name}}</h1>
  {{/each}}
{% endraw %}

Convenient, right? So I’m feeling pretty comfortable with Ember so far, since it reminds me of Rails but written in JavaScript, and the Handlebars templating was super easy to get used to since it’s the same syntax I’ve started using with liquid tempting in my Jekyll blog. I still have a lot more to learn in Ember as I continue over the next couple days, but I’m becoming very intrigued with some of its object modeling features that I was reading up on, since again, it’s the same things I’m used to seeing in Rails, with the model relationships, and designating what the attribute types are going to be, even without dealing with a traditional database. I’m really excited to continue playing with it, and wonder if (or how) I’ll decide that one is better than the other—Backbone or Ember?

More Ember Thoughts

2014-02-02T10:26:00Z

After 4 days of working with Ember, these are my thoughts about it.

Things I Don’t Like About Ember

Input Helpers

They don’t let you use all the same options you’d be able to use in a normal input element, like required=true. You can just use a normal input element, but then you don’t have the luxury of the value binding to a property in the controller.

Automated magic

Ember makes a lot of things easier on you by doing some “magic” behind the scenes, but when those things don’t perform the way they’re supposed to, it’s hard to tell why. That’s the advantage of having to spell everything out yourself–it makes it much easier to fix things when they don’t perform the way they ought to.

Handlebars Helpers

Sometimes they’d work and sometimes they wouldn’t and I could never tell what the deciding factor was.

Model Relationships

I expected these to work the same way they do in Rails with the belongsTo and hasMany, etc. But you can’t reference them the same way you would in Rails and I became very frustrated when trying to display the comments for a post.

The Guides

I felt like the guide on the website was really lacking, at least compared to Backbone’s guides. They read more like a tutorial instead of explaining thoroughly how you use each feature. They do have the API section, which I think is more similar to what I wanted, but it is overwhelming at a glance.

Things I Do Like About Ember

Automated magic

When you’re doing the basic setup for the site, it is really quick and easy. I’m also impressed with the way it updates values that are changed instantly across the site, without you explicitly having to tell it to re-render those items.

The structure

Ember reminds me a lot of Rails, not just because of the MVC aspect but the way they do their routes and models. I like that it reminds me of Rails.

The routing

Speaking of the way Ember does routes, I found it so much more straightforward and easy compared to the built in routing feature of Backbone.js that I ended up not even using, in favor of Page.js. The octothorpe in the url is annoying but I’m certain that could be gotten around the same way you can in Backbone. In the same vein, I like how easy they make it to transition to another “page” with something like this: this.transitionTo(‘page’);

The Chrome extension

There is a chrome devtools extension for Ember and it’s incredibly useful and awesome. I wish Backbone had an extension like that (maybe some day I should build one?)

Final Thoughts

I am intrigued enough to continuing playing around with Ember. One of the things that was frustrating me would not even be an issue if I was using a RESTful API to serve information to Ember instead of using LocalStorage and relying on Ember’s built in model relationships. I also know that a part of getting used to any technology is learning its quirks and how to work around that. So far I think Ember would be better for more simplistic apps, but I would have to build out a site more with it to be certain of that opinion.

Final Thoughts on General Assembly

2014-03-08T09:55:00Z

I’ve been promising to write a wrap-up post about General Assembly and have continued to receive requests asking about what my experience was like and if I think it’s worth it. Now that it’s been almost 3 months since the program ended, I feel I can do a better job of wrapping it all up.

To start with, if you’re someone who hasn’t read my Bootcamp Application Journey post, I’ll reiterate the point that General Assembly was the very last on my list of preferred bootcamps. I went there because I didn’t get accepted into any of my top choices and couldn’t afford Hack Reactor (though I likely wouldn’t have been accepted to Hack Reactor either). Information was so scarce on General Assembly that I questioned whether I might be better off just staying home to study on my own rather than spend the money, but I figured that I’d at least have the benefit of having the instructors to help me get unstuck when needed or to provide guidance. What also ended up convincing me to attend was their apprenticeship program, which I figured was a good worst-case scenario that I’d have no problem getting into.

The conclusion that I came to at the end of the program was that it wasn’t worth $11,500; at least, not at the time that I took it. I’ve been envious of the current cohort at the SF General Assembly because it seems much more like what I was wanting out of my experience and the quality seems higher.

Why I didn’t think it was worth that amount

Lack of the same amenities that other bootcamps give you for the same price

No computer equipment to use
Uncomfortable chairs and classrooms
Lack of space (more on this below)
Lack of coffee half the time (I'm sorry, but this is oh so important and something I explicitly asked about before I agreed to attend)
Lack of a hiring day where you can interview with companies

At first I thought this was a benefit that General Assembly doesn't take recruiter fees for placing students with certain companies, but after seeing how effectively the other bootcamps were getting their students hired, I decided this was a downside.

They won’t tell you who the instructors are before you start, so you have no way of knowing what the quality of teaching is going to be like.

Way less time to learn than advertised

Consistently starting late
Consistently having long lunch hours
Consistently having breaks run long

It lacked structure. They had two different classrooms for our cohort where we were supposed to be generally learning the same thing at the same time, but that was often not the case. We’d compare notes and it was always so different, to the point that sometimes one class wouldn’t even get to the things the other class was learning. The lessons often seemed disorganized and frequently had errors.
Catering to those who aren’t paying attention in class. There would be students who would sit there in class watching Netflix or browsing Reddit while the instructor was talking, and then the student would suddenly look up and ask the instructor to explain something they had just finished explaining, and the instructor would comply. Sure, this type of thing happens in most schools, but this isn’t supposed to be most schools. It’s supposed to be an intensive bootcamp that you are paying a lot of money for to learn and I felt that my opportunities to learn kept being stolen from me.
No queue system for help until the end of the 5th week, so it was often hard to get assistance. Sure I can google things as well as the next person, but I wasn’t paying GA $11,500 to get assistance from the internet, which I could have done from home.
The student code of conduct was kind of a joke. The standards are not high, and they did not enforce any of it. Students could show up whenever they wanted, without penalty, and then the instructors would try to catch them up. They say you have to do all the pre-work before the first day of class, or else you won’t be able to start, but that wasn’t true at all. A lot of people said they didn’t do the pre-work and it showed because we had to spend the first couple weeks going over all the pre-work and teaching it to people who didn’t do it. I’m sorry, what did I waste those 50 hours doing the pre-work for when I could have just learned it in class?
Lack of space. We’d be kicked out of the classrooms at 5:30pm on the dot and there’d be no where else for us to do our homework at General Assembly. This frustrated a lot of my classmates because we wanted to get work done around our peers. General Assembly advertised that we would be able to work up in this other area after class ended, but they were having other classes up there most of the time. Towards the end of the 3 months they tried to make more space for us by moving the staff from the main area to another office, but by then the course was mostly over.
Other classes being disruptive by being noisy. The noise from both the UXDi class and the mezzanine classes were a recurring issue, and yet if we were the least bit noisy during our break we were yelled at.
We were told that we’d be doing so many mock interviews that we’d be sick of them. Not true. There was one mock interview, and then I managed to squeeze in another one with an instructor at the last minute during final projects. I felt so unprepared, and unfortunately was unable to practice the pointers they gave me since that was it. No more class.
The curriculum said they’d teach you pair programming but there was only a single instance in the entire course that they did a lab where we had to pair program. On that note, there were other things listed in the curriculum that didn’t get taught either.

Complete lack of feedback. The website advertised that you would be receiving feedback on your progress every week from the instructors and that there'd be one-on-one attention. The first couple weeks we weren't even getting any feedback on our homework, let alone feedback on how we were doing. You can only really judge yourself in these instances to a certain extent. I really wanted to know what they thought of my solutions and if my code was messy, etc. The one-on-ones with the instructors were sporadic. We did 3 major projects in the program and I didn't receive any feedback whatsoever on the first 2 I did. I was shocked when people came up to me after the 3rd and final project to tell me they really liked it, since I was used to no one mentioning the projects at all.

On that note I was also disappointed and depressed after the presentations of the first project. To work so hard on something and then have them rush through your presentation because they're anxious to get done so the class could start drinking (full disclosure: I'm not much of a drinker) and then not ever get to hear how I did on the project and having it just be dismissed—that was frustrating. It was after that first project that I really wanted to just drop the program. Weeks of being unhappy with the quality of the program culminated in this event and the following week was the first time I missed turning in a homework assignment because I thought, "Fuck it, it's not like they'll notice or care."

Our cohort ended up not getting an apprenticeship program due to lack of participation from any companies. Since this was the deciding factor in me even attending, I was disappointed and furious. I thought they had more established structure in place. I think they need to be more transparent about this on their website; that the apprenticeship program is not a definite thing that is available to every cohort.
I was told that 96% of students get the kind of job they were looking for within 3 months of the program ending. Either that statistic is invalid or our cohort changed it drastically. Some weren’t looking for jobs after the program ended and were just doing it to enrich themselves. At this point, out of the people who were wanting jobs afterwards though, only 1 of my classmates has gotten a full-time position as a Ruby on Rails Software Engineer; 4 or 5 have gotten internships for front-end and full-stack (I believe); and a couple went back to what they were doing before the program after unsuccessfully finding anything. The rest are still looking for something.

Things I Did Enjoy About the Program

I learned tons more about back-end development, just not enough to get an entry-level position doing back-end/full-stack.
It really lit the fire under my ass to create project after project to practice, learn, and produce. I created much more during the program than I’ve created in years.
I finally got some experience using Github to collaborate instead of just using it as a versioning system for myself.
It increased my confidence as a web developer because I knew so much more about the entire stack.
I met some really great people in the course whom I now continue to be friends with.
Getting to take a few field trips to local companies, see their offices, and hear about how they do things was pretty awesome.
The producer and administrative staff are really nice and I definitely felt like they wanted to help me succeed.

Final Thoughts

I know some of my classmates thought I was taking things way too seriously, but this wasn’t just something to do on a whim, or that parents were paying for, etc. This was my life. Failure was not an option and it was a big risk for me to take out a loan when I was already so much in debt, without knowing whether it would pay off, not to mention my happiness being on the line. As it turns out, General Assembly just wasn’t the right bootcamp for someone like me who was looking for a high-intensity learning environment where everyone was really dedicated. I know I would have enjoyed a place like Hack Reactor far better or even Dev Bootcamp.

The bootcamp experience is different for everyone, even in the same cohorts. It’s a work in progress, and it can be especially different depending on what your personal goals are, and what you hope to accomplish. I know some of my classmates were satisfied with the experience and I know some who were upset with the same things I was. Do I think it was better than staying home to continue learning on my own? Absolutely. Do I think it was worth $11,500? Not at all. I think the price tag should have been reduced, but maybe the quality has changed and it’s justified now. That’s something you’ll have to decide for yourself. This all really only reflects the experience I had at the time.

One of the big questions people have emailed me to ask is whether someone who has no programming experience can really get a job after doing this program. In addition to the statistics of my classmates above I’ll say this:

Right now the San Francisco Bay Area is flooded with entry-level software engineers. There is no shortage of developers, but there is a shortage of skilled developers. I was constantly lauded by my classmates for being really good at programming and I was told by a member of the staff that I was one of the top students they had ever had in any of the cohorts. On top of that all my friends work in the local tech scene and I have great contacts and lots of opportunities to network. I still couldn’t find a job as a Ruby on Rails developer. My opinion is that General Assembly would be a good start to your learning, but you’re going to have to put in a lot of work afterwards to continue gaining skills and experience. Don’t expect to come out of this bootcamp and have a job right away.

Since companies are only interested in my front-end development skills (I’ve been doing front-end for half my life), I finally accepted that I’m just going to have to continue doing front-end and hope that I can slowly work myself into a full-stack role eventually.

Drag from Desktop Tricks

2014-03-26T21:09:18Z

Lately I’ve been reading a whole lot about drag and drop while I’ve tried to implement a ‘drag from desktop to upload’ feature. While some of these features have been around for a very long time, others are new and therefore finicky.

One of the annoying things about dragging files from the desktop is that there are only 3 events that the browser will recognize for this target: dragenter, dragover, and drop; whereas when you drag items that are already in the browser you also have dragstart, drag, and dragend. I read a lot of articles telling you that you can’t do these things, but I wasn’t satisfied with that. I knew there had to be a way to cheat. There are in fact a couple ways that you can fake the drag start and drag end events. Here are the tricks:

On Drag Start

If there’s nothing that you want to happen when an item starts being dragged then you’re a lucky person, because you won’t care that you can’t initiate anything at the beginning of a drag. But what if you want a drop zone to become apparent when an item starts being dragged, or some other kind of notice or action that helps the user? There might be multiple ways to get around this, but the best way I’ve found so far is to simply attach an event listener to the body tag for dragover like so:

var page = document.getElementsByTagName("body")[0];
page.addEventListener("dragenter", doSomething, false);

function doSomething(event) {
  event.stopPropagation();
  event.preventDefault();
  
  // Whatever action you want performed when the drag starts
  
  return false;
}

This works well because of course the body covers every last inch of your viewport, so as soon as the dragged item enters the window it’ll start picking up that something is being dragged, so you effectively are faking a dragstart event.

On Drag End

Here’s the tougher one. Most people will find themselves wanting something to happen when the dragging has stopped, even if it’s just telling the hover CSS on the drop zone to go away. It’s pretty easy to take care of any drag end actions if something has been properly dropped in the drop zone, because then you just tack on all the actions to the drop event. What if they stop mid-drag, however? Say you have the drop zone light up when an item starts being dragged and halfway there they let go of the mouse for whatever reason. Oops, the drop zone is still lit up and could even be preventing further actions. The way I solved this last one is by adding an event listener to the body once again for a drop event.

var page = document.getElementsByTagName("body")[0];
page.addEventListener('drop', doSomething, false);

function doSomething(event) {
  event.stopPropagation();
  event.preventDefault();
  
  // Whatever actions you want to stop doing when the drag ends

}

This is effective for two reasons. One is that up to date browsers will automatically open files that you drop into them and you don’t want to have that happen if you’re letting users drop things in from the desktop and want to prevent the default behavior if they accidentally miss the drop zone. That’s why those preventDefault() functions are so important. You’re saying, “Hey browser, don’t do your thing because I’ll take it from here.” Then the second reason is to of course cancel any actions that you were performing on drag. This will probably be the same thing you were telling the ‘drop’ function to stop doing once the item was properly dropped.

Now here’s where it got tough. What if instead of prematurely letting go of the item somewhere on the page, they drag it back to the desktop and let go? How do you account for that? I played around with a couple possible solutions, such as listening for the mouseleave event on the body but just like the drag events, the body won’t recognize a mouseleave event that takes place when you’ve dragged something from outside the browser.

The answer ended up being what takes place after that: the mouseenter event. Once they’ve dragged something back to the desktop the mouse has to re-enter the body again if it wants to do anything on the page and it will be without the dragged item, so voila!

var page = document.getElementsByTagName("body")[0];
page.addEventListener("mouseenter", doSomething, false);

function doSomething(event) {
  event.stopPropagation();
  event.preventDefault();

  // Whatever actions you want to stop doing when a drag ends
  
}

It’s not an ideal solution of course because you’ll have a lot of unnecessary events triggering if the user just happens to keep waving their mouse in and out of the browser, but it works and is better than the alternative of your users no longer being able to use the drop zone areas because they’re blocked by new CSS items or overlays, etc.

And finally a working example for you—try dragging a file in from your desktop and performing the scenarios mentioned above.

I’d love to hear any better ideas people have come up with for mimicking the drag start and end events; feel free to comment!

From Coupa to Glassbreakers

2017-09-03T21:09:18Z

It’s been way too long since I’ve written a post on this particular blog, so what better occasion than to announce that after 3 1/2 years I have left my job at Coupa Software. My last day was on August 18th and I will certainly miss the friends I made there, but it was definitely time for a change.

So one week ago I started my new role at Glassbreakers, which is a much smaller company and located closer to home. I am very excited about this new adventure and looking forward to the future. I also am excited that my new job will allow me to have a much better work/life balance so that I’ll get more time with my kids and actually have time for my passion projects. Looking forward to talking more about those soon.

I may even finally have a chance to upgrade my personal site’s infrastructure and give it some much needed TLC. Here’s to hoping :-)

A Sort of Love Letter to HTML

2018-01-01T17:00:00Z

I’ve been studying HTML since 1999, and like everything else it has grown and advanced over time, and I’m still learning new things you can do with it all the time. Unfortunately it tends to be one of the under-appreciated parts of web development, especially for those coming from a background of backend development. I want to explain some of the major points about why it is worth all developers time to fully understand it in order to have a more effective front-end.

Performance

We can all agree that we want our websites to be fast, right? One of the ways you can do that is by simply reducing the amount of DOM nodes on a page, or in other words, using less HTML elements. But wait, didn’t I just say, “Yay! HTML is the best! HTML for life!” Truth, but less is more. You want to use HTML effectively, and just like we don’t want a bunch of messy spaghetti JavaScript around, we need to respect the structure of the page and be strident about using the best tool for the job as you build the foundation of each page.

Here’s why:

The more DOM nodes you have, the longer it takes to download that page from the server. HTML usually isn’t responsible for the major chunk of page load time, that award tends to go to images and scripts, but every little bit counts!
CSS has to parse the entire DOM to figure out where it needs to apply the styles, and of course CSS performance in itself is a huge topic we won’t get into. The point is that the less unnecessary HTML elements on the page, the less work the stylesheets have to do, which results in better performance.
Likewise, when you are querying the DOM in JavaScript or jQuery, the more DOM nodes you have, the harder it has to work to find the element you want. This is why developers tend to save the queried element into a variable when they’re working with it, because it takes precious milliseconds to query it again and again. But why not make that initial search as fast as possible as well?

Every time I am working heavily on the HTML of a particular page for the first time, the first thing I’ll do is go through and rip out all the superfluous elements. I clean house, so to speak. So now you’re probably asking, “What are all these superfluous elements you keep talking about?” Basically, I’m talking about any element that does not need to be there for the look of the webpage to remain the same. The biggest offenders are pretty easy to spot.

Here’s what to keep an eye out for:

`<div>`'s and `<span>`'s that have no classes, IDs, or attributes

There might be a good reason that you have a <div> as a container for a collection of elements because of its inherent block properties, or maybe you have the styling on the parent element that targets all of its children, but more often than not if I see a bunch of plain <div>'s being nested, they are serving absolutely no purpose whatsoever. Along the same lines, those plain <span>s are usually a red flag. The entire purpose of a <span> is to be able to target something small that you want to style differently than everything else around it.

Like this span page from MDN says, “It should be used only when no other semantic element is appropriate,” and if you look at that page, you’ll see that both examples show it being added unnecessarily. The first, because it is unstyled and does absolutely nothing. The second example is unnecessary because the background-color can be put on the <li> element. A much better example of a proper use case is:

<p><span class="blueText">Blue</span> is my favorite color</p>

Where there would be a class that makes that one word Blue, and the rest of the text in the paragraph is a different color.

Another thing to look out for is multiple <br/> tags in a row. This is usually a sign that the element correct element.There are other elements that might be hanging out for no reason, too, but I’m focusing on these because they’re the two biggest offenders that I have come across.

Empty Elements

I tend to spend a lot of time in the browser’s inspector, and sometimes I’ll see multiple elements that contain nothing. Not elements like the ones in the previous section, but elements that look like they should actually be doing something, because they have IDs, classes, and/or attributes.

<div class="importantThing blueVelvet">
</div>

So I immediately wonder why it’s there and go look up the code, and it’s almost always the result of some conditional.

<div class="importantThing blueVelvet">
  <% if user.city %>
    <%= user.city %>
  <% end %>
</div>

Or what I tend to see in React code is that there won’t even be the conditional, but it’ll have a variable value there that happens to be blank, so you see nothing on the page, but these nodes still are clogging up the DOM for no reason. Now as with anything, there are perfectly good use cases for having placeholder elements in the DOM, like if you know you’re going to be loading something there dynamically, for example. But if that’s not the case then I encourage you to place the HTML elements within the conditional and if there is no conditional, add one!

Using the right tool for the job

Sometimes you can reduce the amount of nodes by simply using the proper HTML element, which is why it’s important to be familiar with them and what they do. Every HTML element has inherent properties and semantic value: there are block level elements, inline elements, elements that have more meaning than others (semantics). The elements behave in different ways and if you aren’t using them for what they were meant for, you might have to have extra elements, and you might have to add more styling than would have been necessary. A really extreme example would be putting a <div> on a page with some text that you want to click on in order to visit another page by adding an onClick handler to that <div> and then making an AJAX call or calling window.location("/link.html"). You’re probably not going to do that right? Why go to all that work, when you can simply use a normal <a> tag for your link that has all that functionality built into it?

Some less extreme, but common examples are cases like the multiple <br/> tags I mentioned above. If you are trying to put extra space between two blocks of text, then you probably aren’t using paragraph tags and should be. If you are separating out chunks of text within a single paragraph tag, then you aren’t using enough paragraph tags. Paragraph tags are block level elements that inherently have spacing above and below them.

Another example would be changing a <span> through CSS to be a block-level element instead of just using a <div>, or adding a bunch of CSS/JS to make a <div> act like a button instead of just using the <button> tag. You get a lot of functionality for free when you use the proper element. Buttons are inherently tabbable, they can use the disabled attribute, and they also have many special HTML5 attributes that can do lots of things.

In general, I encourage you to explore all that different attributes that can be used on a particular element, because that’s how you learn just how powerful HTML can be, which brings me to the next special mention: HTML5.

You might not need CSS/JavaScript

You’ve probably seen “You Might Not Need jQuery” and “You Might Not Need JS”, but I’m here to tell you that you might not need anything but HTML. If you’re an old school developer, you might not be as familiar with all the fantastic things you can do with plain old HTML elements, and I’m always surprised that HTML5 isn’t used more being that it’s pretty old now. One of the areas it really shines is with forms.

You have an input field and you only want the user to be able to enter numbers, so you have a backend validation to ensure that the value is numeric when it hits the server. Backend validations are important; they are the last line of defense before it hits the database, but why waste that time traveling all the way to the server initially? So you decide to implement some client-side validations to catch it without making a server call, and that’s pretty easy to do using isNaN(value) or $.isNumeric(value), but if you’re doing that, then you’re working way too hard. All you have to do is tell your field what type it should be: <input type="number"> and it won’t even allow the user to enter anything but numbers. “But what if I want to make sure they only enter positive numbers? Or limit it?” you might ask. You still don’t need JS. Other attributes you can use on that field are min and max.

This is just one example, but there are many other special input types that can be used in forms that almost completely eliminate the need to use JavaScript for validations or to restrict input. Some of them even do fancy things that previously developers would have used a special plugin for. You want the user to input a date and want them to be able to choose from a pop-up calendar? <input type="date"> will do this in every browser but Safari and Internet Explorer (sadly it falls back to a normal text input field), so plugins aren’t completely obsolete in that case, but it can fit a lot of use cases. Another fun one is <input type="color"> for letting users pick a color from a pop-up palette. I encourage you to explore all the different input types and their attributes.

Accessibility (A11y)

Another very important reason to understand HTML and its proper uses? Accessibility is important. I won’t elaborate all the reasons why because there are countless articles and books that will do that much better, but I will sum it up by saying that your website being accessible enhances the user experience for everyone. I’m also not going to talk about all the techniques to make your site accessible because that’s a huge topic all its own. What I want to focus on, in the spirit of this article, is how using proper HTML elements (the right tool for the job, again) will already make your webpage much more accessible than it would be otherwise.

Semantic HTML

I suppose having also studied print design and typography, that my love of clean layouts and meaningful structure has also carried over to web development. So I was pretty excited about the increase of semantic tags when HTML5 came around. Providing more meaning to the elements not only helps accessibility but is an all-around win, in my opinion. Long gone are the days where <div>s ruled the lands. Now we have <section>, <article>, <aside>, and so on. Even before HTML5 though, there were a large amount of tags that weren’t being used when they should be.

Let’s take tables for example. Tables no longer rule the web either, but they still have a good purposes and lots of associated tags that go with them. Yet somehow I’ll see table after table only make use of <table>, <tr>, and td, oftentimes with the first table row trying to act as headers. If a table has headers, it should at the very least be using <th> for the header cells, but ideally using <thead> as well. The browser will treat these differently than just another table row, and semantically it means something.

I still see <i> and <b> used more often than <em> and <strong>, probably because old habits die hard. The former still have uses, but the latter should always be used when you’re trying to place actual emphasis on something; not for styling reasons, but because of the meaning it conveys.

How proper HTML helps keyboard accessibility

All sites should be fully accessible by keyboard, and there are certain keys that users expect to be able to use to do this, because it’s the standard. Most people know they can tab through form elements and tend to do it without thinking about it. This is another case where you want to use the right tool for the job, because the exact kinds of things on the page that the user would want to navigate to are tabbable by default, without you having to do anything. This is why structure is important, and this is why the right element is important. Links, buttons, and input fields all have that functionality built in. This is why you don’t want to use a <div> in place of a <button>, or a link that doesn’t actually use an <a> tag. It is also why the order of elements matter, because tabbing follows DOM structure, and not the visual structure on the page. So if you’re floating <button>s and they appear in a different order on the page because of it, that’s going to confuse the user when the element they expect to be selected does not actually get selected.

Sometimes that’s not going to cut it. You might have a link menu hidden as a dropdown, and then you’re going to have to make that parent element open and close when tabbed to, but by being mindful of using the right elements for the job, you’re still halfway there.

Links also accept the “Enter” key by default. So if you are focused on a link and hit enter, it will go to that link. In forms, if you are focused on any input field within a form and hit enter, unless there is underlying code telling it to not behave like normal (here’s a nice article about why you should rarely suppress this), it will automatically submit the form.

How proper HTML helps screen-readers

There are a large amount of people in the world who have visibility issues, so they make use of screen-readers, and there is no feature that you as a developer turn on for this to work. A screenreader can read what’s on any website, but how much of that is coherent does depend on what you as a developer have put there. This is why the aforementioned semantics are important, but there are also some basic HTML attributes that aid screen-readers. One that most people know about is the alt attribute on images (alternative text), and yet it is so neglected. It’s often left blank when it shouldn’t be, filled in when it shouldn’t be, or the information doesn’t describe the image at all, rendering it useless. Let me hit on each of those points:

If it is important that a particular image is conveyed to the user (a graph, a visual representation of something being described, etc) then you absolutely want an alt attribute.
If the image is completely unimportant, like a visual flourish, or an icon to represent text that comes immediately before or after it, then you do not want an alt attribute. Why? You’re not only throwing a mess of unimportant information at the user, but in many cases you’re just making it repeat the same word twice, which is confusing. This is also where ARIA roles come into play, but the most basic thing you can do in this situation is to intentionally identify a blank alt="" attribute. If you don’t put in any alt attribute at all, the screenreader/browser will just guess it by reading the file name or title.
If you have an image of the user and your alt text is “User”, or it’s the logo of your company and it just says “Logo” or “Company Name”, you are not helping anyone. At the very least be a little more descriptive: “Your profile picture”, “Company Name’s logo”, but even better, be really descriptive if it’s an important visual. “Image of a brown horse with black hair” helps you imagine something much more than “Pic of horse”.

Another common misuse of HTML I come across is not labeling input fields. All input fields should have an associated label element and this is not accomplished by just having text near an input field. It may look fine to you visually and you might be able to deduce that they go together, but screen-readers won’t. Screen-readers expect that any input field that is selected should be able to tell them what that input field is for. There are two main ways to make sure your fields are labeled properly. The first is to simply wrap your input field in the <label> element like this:

<label>
  Your name
  <input type="text" name="name"/>
</label>

I know some developers might not like to use that method because they have special styling on all <label>s that they don’t want on the <input> field and that’s fair enough, you just have to get explicit, and this is where I see the HTML fall way short.

<label>Your name</label>
<input type="text" name="name"/>

The above does not associate the label with the input field. Proximity does not equal association. This is where the for attribute comes in.

<label for="userName">Your name</label>
<input type="text" name="name" id="userName"/>

The above associates the fields by matching up the for attribute with the id of the field. If your for attribute and id attribute don’t match up, then it does not work (I see this happen a lot). Sometimes you might not want the label there visually, or have an extra field associated with that same label. No problem, you can either hide the label, or add an ARIA attribute to the input field that specifies the labeling, but never just leave a field label-less. Screen-readers don’t read placeholders. I should also note that if you want your form elements to be fully accessible for all screen-readers then it’s best to cover your bases and have both the for attribute AND nest your input inside the label.

An added benefit of labeling inputs properly: they’re easier to select and click, which makes them more accessible! Especially checkboxes and radio buttons, which have a very small click area. This is because it allows you to be able to click on the label text to select the element. Also note that for radio buttons, you should use the <fieldset> tag to group the radio inputs together, where the <legend> serves as the parent label while each input still has its own.

These are things that should be considered the basics of HTML, making use of the built in attributes and structure to better serve a diverse user base.

You don’t have to work as hard

If anything else, understanding HTML should be encouraged because it makes your work easier. It can reduce the need for both styling and scripting, and makes the world wide web a happier place.

Abbreviations

HTML: HyperText Markup Language
DOM: Document Object Model
ARIA: Accessible Rich Internet Applications

A Mental Checklist When I Do Code Reviews

2018-07-25T05:09:18Z

Some of the things that I’m thinking about when I am doing a front-end code review…

TL:DR

Accessibility
Cross browser compatibility
DRY/DRW
Maintainability
Performance
Security
Style/Formatting
Tests

I’ve done my fair share of code reviews over the years, and continue doing so on an almost daily basis. At my old job, you would usually only perform a code review if you were requested on one, and I remember being so excited when I started being requested for them because it meant that I would have the opportunity to prevent bad front-end code from getting into the codebase in the first place (a <span> for every element on the page, anyone?) But I soon learned there’s much more to code reviews than just preventing bugs or pointing out stylistic issues. They are also a great learning experience. I’ve learned so much from reviewing other developers’ code over time, and it not only made me a better programmer, but has made me more thorough in my reviews—and in some of the positions I’ve held, you have to be, because there’s a lot more at stake.

There are lots of articles out there about how to do code reviews, why you should do code reviews, and so on. I’d like to talk about what I look for when I’m performing code reviews, also known as: the things that I think about when I’m writing code. I’ve never made an official checklist, though it’s often helpful when a team/company decides amongst itself what it considers important, and has checklists and/or guidelines to follow; but this is basically a mental checklist I think of every time.

Accessibility

This is a first class concern of mine, and what I find a lot of people don’t realize is that if you are writing semantic HTML and using the right element in the right circumstance, then you’re already writing mostly accessible HTML. So I’m a stickler about using proper HTML, and this tends to be where a lot of my comments lie. Are you using the right element? Are you using the correct attributes? Are you thinking about structure and layout? Are your images presentational or do they need to communicate something? Are you making sure interactive elements show focus properly? And so on…

Cross Browser Compatibility

Let’s be real here, not only do a lot of people not have the luxury of developing for only the most modern browsers, but even the most modern browsers have quirks. Sorry folks, some things just aren’t going to look or act the same way in Firefox as they do in Chrome. You might not be familiar with all the quirks, known issues, or what is now standard, and that’s okay, but if you write front-end code then you should always be checking that what you’re writing looks consistent and works in all the major browsers your company supports. Download them all and get used to using them. Bookmark caniuse.com, and get yourself a VM. No excuses. You develop for the world-wide web. (Also please don’t use vendor prefixes for CSS declarations that have been standard in all browsers since 2008, because it’s unnecessary weight).

DRY/DRW

Everyone is familiar with “Don’t Repeat Yourself”, so yes I look out for repetition when someone is performing the same action over and over and it would be better to extract it into a method. However, there’s a bigger issue I tend to see that’s similar, which is “don’t recreate the wheel.” There are often duplicates of functions/methods that do the exact same thing and yet more will be added. When I’m working on a new area of a codebase that I haven’t worked on before I try to do a quick read-through of the classes and their methods to see what is already available to use and might pertain to the new enhancement/feature I need to create. Whoo hoo, less work, this query already exists, and so on.

In the same vein it’s also good to have re-useable components in an app not only for ease of use, but to keep an app looking/behaving consistently. So I keep a look out for anything that looks suspiciously like something that already exists. There’s another part of this too though, and that’s doing a whole lot of unnecessary work to create something from scratch that you can get from a library that is tried and tested. I’ll say that most of the time I find that libraries/plugins are added to codebases unnecessarily and weigh down the app when it could have been written much simpler. But there are valid use cases for using a library/plugin instead of rolling your own. I often remind myself of this when there’s some new functionality that needs to be introduced that has probably already been done bulletproof before. So it’s always good to check and see if you can find something that simply and effectively fits your use case before spending months recreating the wheel that could be much faultier.

MAINTAINABILITY

This actually kind of ties in with DRY, because I often see places where partial templates or helper methods would prevent future disasters of having to remember to change something in all these different spots, where it’s not necessarily a “find and replace” sort of scenario. I used to work on a very large enterprise web app that had existed for 8 years before I got there, and I can’t tell you how many times I saw something get changed in one spot but no one thought to update it in other spots, which caused bugs and customer aggravation, so I suppose I’m a little hyper aware of these things. I suppose the point is: be kind to your future self and the future others who will work on this code. If you can’t be DRY, then at least document things and leave directions. I’ve heard some argue that code should be written clearly enough that comments aren’t needed, but code comments should explain WHY and not WHAT, and sometimes how things connect to each other. You’ll thank yourself later.

PERFORMANCE

I find a lot of people are somewhat cognizant of performance if they’re writing queries, but don’t necessarily take it into consideration in other circumstances. I try to think of the cost of everything I add, and the larger picture. (Side note: I take pride when I can delete more code than I add in). Best case scenario: people are just impatient when browsing your site. Worst case scenario: people can legit not access your site on mobile or in areas with lower speed internet. Think of performance always.

What this means for me usually comes down to a lot of front-end issues. Are you adding more DOM nodes than necessary? Why does it take 5 nested <div>s to render a line of text? Are you using an HTML element improperly, causing you to have to add a ton of CSS to make it behave like a different HTML element? Are you loading a ton of JS and/or CSS that will never be used by this page? Are you fetching large images from the server only to have CSS show it smaller? Are you adding unnecessary JS instead of just using an HTML element that already does that? (I once had to explain to someone that you can just use the “target” attribute on a link tag to open up the link in a new tab instead of writing extra JS to do the same thing). And if you are adding necessary JS, are you making sure that it is performant? Or are you re-querying the DOM over and over unnecessarily? And you looping through items in an inefficient manner? Or on the server, do you have an action being performed before every single call, when it doesn’t need to be? Obviously there’s a ton that goes into front-end performance, and the more you can help people be aware of all the little ways it can be affected, you can slowly get everyone to improve it over time.

SECURITY

Of course it’s always good to check for the oldies but goodies: XSS, SQL injection, unencrypted data, but as we experience a growing number of front-end frameworks being used that handle lots of information passed in from the server, I find myself having to check more often that sensitive information isn’t being exposed in the DOM that shouldn’t be, and people can easily be tripped up by that, especially when server rendering React components. I think developers are so used to being able to manipulate data on the server safely before rendering an HTML view that it just doesn’t occur to them that you can’t just blindly pass that same data to the front-end for it to use. So I’ve tried to start being extra careful myself about only giving the front-end the data it actually needs and remind others as well.

STYLE/FORMATTING

In an ideal world you have a set style guide that everyone has agreed upon, and you have linters and/or formatters assisting in doing the heavy-lifting so that you don’t have to, but that’s not always the case. I’ve learned to not be nit-picky about style and let a lot of things go. When it comes to possible errors, however, I try to pick up the slack when the linters aren’t enough. Missing semicolons are an issue when you want to minify your JS (see Performance). Forgetting a closing </div> can completely break Internet Explorer (see Cross Browser Compatibility). In other words, these things do matter.

TESTS

Not much to say here. Most of the time I like writing tests, and I feel a special delight when they catch a legitimate bug, but there are certainly moments when I’m feeling lazy and wish I was just done with my current task, but I always overcome it, suck it up and do it. Tests are important, and I think most people would agree to that. I don’t often have to ask, “Should there be a test for this?” I do often comment though on how tests could be better, because they either have redundant scenarios or take too much time to run because they’re not taking advantage of time saving measures like not writing to the database superfluously. Sometimes the assertions aren’t asserting what they say they’re asserting, which is also wasteful. So I make sure to give tests just as much attention as the rest of a pull request, because fast test suites equal happy developers, and accurate tests equal happy everybody.

TYPOS

The truth is I don’t actually look for typos but have accidentally been a human spell-check for as long as I can remember. I’m good at proofreading. It is rare that I don’t notice misspelled words when reading things others have written. Advantage or curse? You decide. Honestly it’s kind of annoying.

THE BIGGER PICTURE

A lot of these things would be considered being among the weeds, and it’s always good to keep in mind the architecture of the application and how it all fits together, which can be harder to do if you’re looking for some of the smaller things. That’s something linters and pre-commit hooks can help with; taking care of the little things so you don’t have to and then it’s easier to notice things the author may not have noticed or thought of because they were so deep amongst the weeds. A second pair of eyes can always help, because they’re looking at something fresh. I had an art teacher in college who would often remind us to step back from our work and view it from across the room. It is very beneficial.

I hope this encourages others to start thinking about some of these elements if they aren’t already. And finally, I always look for cool things that the author did and make sure to comment on it, whatever it may be. Maybe it’s great test coverage, or a cleverly named method, but we all work hard and it’s nice to be acknowledged.

Project: Is Alameda Exploding?

2018-08-17T20:55:00Z

I live on the island of Alameda in the San Francisco Bay area. We are bordered on our east side by the Oakland Coliseum and our west side by AT&T Park just directly across the water 3 miles away. When there are fireworks in either of these places we can hear them, and sometimes see them. On holidays we hear all the surrounding fireworks. We also get Blue Angels flying over and so on.

Map showing Alameda and its surroundings

In short, we’re used to hearing noises, and I usually turn to my husband and say, “Must be sportsball” and shrug. But a week and a half ago as we were hearing all kinds of fireworks, my husband said, “I wish there was just a site I could go to in order to verify why I’m hearing fireworks.” (It was the A’s winning a game.) Which in turn made me think of the site “Is Oakland on Fire?” and thought it’d be fun to make something simple like that.

So this week I decided to quickly bang something out and got really excited to actually be working on a personal coding project for once, since I tend to not have a lot of time for my own.

Holidays

I figured Sinatra would be perfect to quickly get something up and running since it’s only a one page site, and then started out by looking into any plugins or API’s that would easily give me a list of holidays. Since I really only care about the ones that have fireworks, I could have hard coded the information but really wanted the site to be as automated and easily maintainable as possible. I ended up finding this Holidays Ruby gem which was perfect for what I needed. It makes it easy to also check if there are any fireworks holidays that week, since for Independence Day we tend to hear things in the days before and after, even though they’re technically illegal.

FIREWORK_HOLIDAYS = [
  "Independence Day",
  "New Year's Eve",
  "Lunar New Year's Day",
  "The second day of Lunar New Year",
  "The third day of Lunar New Year"
].freeze

def check_holidays
  logger.info "Checking Holidays"
  today = Date.today
  holidays = Holidays.on(today, :us, :hk)

  # Might be the week of Independence Day, etc
  if holidays.empty? && Holidays.any_holidays_during_work_week?(today)
    holidays = Holidays.next_holidays(1, [:us, :hk])
  end

  # We only care about the holidays that might have explosions
  holidays.map { |holiday| holiday[:name] }.detect { |hol| FIREWORK_HOLIDAYS.include?(hol) }
end

There might be some additional holidays to add, but I’m going to wait to expand it. Also since holidays don’t regularly change, I will be adding caching soon.

Sports

Then I figured the most heavy duty part was going to be finding the information about the sports games. I assumed I was going to need to use web scraping to get the information and started setting up Nokogiri and HTTParty. I quickly realized, however, that all the websites I wanted information from use JavaScript to load the information in after the initial page load. I haven’t done much web scraping before and did some research about how to address this and quickly came across this page that mentions just accessing the urls that are bringing in the information, since JavaScript is usually accessing JSON anyway before manipulating it on the front-end. Of course I read this and went, “Oh duh, that’s way more straightforward.”

So I found the behind the scenes URL’s on all the sports sites and ditched Nokogiri, since it was completely unnecessary, and just started looking through all the JSON being returned to find the information that I needed for my purposes.

class Scraper
  attr_accessor :check_for_games

  ...

  def grab_page_info(team)
    case team
    when "Athletics"
      HTTParty.get(baseball_url("531221"))
    when "Giants"
      HTTParty.get(baseball_url("531220"))
    when "Warriors"
      HTTParty.get(basketball_url)
    end
  end

  def winning_baseball_game?(response)
    response = response["dates"].first

    home_game = response["date"] == simple_date && VENUE_NAMES.include?(response["games"][0]["venue"]["name"])

    return false unless home_game

    night_game = response["games"].first["dayNight"] == "night"
    is_winner = response["games"].first["teams"]["home"]["isWinner"]

    home_game && night_game && is_winner
  end

  def check_for_games
    games ||= []

    SPORTS_TEAMS.each do |team|
      puts "Checking site for #{team}"

      response = grab_page_info(team)
      return unless response.code == 200

      if team == "Warriors"
        home_game = response["games"].detect do |game|
          game["home"] == true && game["date"] == simple_date
        end

        games << team unless home_game.nil?
      else
        games << team if winning_baseball_game?(response)
      end
    end

    games
  end
end

And that was basically it. I put it up on Heroku and then started fiddling with it to make it faster. I ended up adding IronCache to store the results after the JSON had been retrieved and parsed, which was the biggest bottleneck.

Summary

It’s a bit of a frivilous project, but it was fun. Here are some of the variations of what you might see.

In the future I will probably add some checks for whether it’s Fleet Week, and other such loud disturbances to expand it. Hope the Alamedans enjoy it! You can check out the live site or view the project on Github.

Dynamic Imports of JSON

2019-08-18T23:38:00Z

TL:DR

If you want to do a dynamic import of JSON with Webpack be sure to account for a JSON file not having a default export when you’re trying to extract the value and call default on the returned module to return the whole JSON object.

As someone who has been around the web development scene a long time and has often worked on large enterprise software that is behind the times, it can be hard to keep up to date with all the latest technology and trends when you don’t have opportunities to use it every day at work (and you have two small children at home to take care of). So I’ve been trying to find some extra time the last couple months to study up on all the tools that I’d be using at my new job and signed up for a Front End Masters account to help me brush up.

One of the tools I had used before but had never taken the time to fully understand was Webpack. I had only used Webpack at one previous job and only for 4 months so I knew I wasn’t using it to its fullest potential, and recently I learned how to do dynamic imports with Webpack and that was particularly exciting as someone who has specialized in front-end performance in the past. If you haven’t been introduced to dynamic imports yet it is helpful for solving performance issues by making sure you’re only serving up larger bundles of code when you actually need it, and it’s all regular JS under the hood.

Working with modern JS you often see static imports for modules:

import myLib from './myLib';

But dynamic imports aren’t grabbed from the server until runtime. Using Webpack and the dynamic import structure it creates a promise that will retrieve the chunk at runtime and allow you to act on it at that point. Simple example:

// This creates its own bundle chunk
const myLib = () => import('./myLib');

myButton.addEventListener('click', (e) => {
  // Chunk only downloads at this point and then you react to it
  myLib.then((libFunc) => {
    libFunc();
  });
});

After learning about this through the video, reading documentation and examples, and practicing it on my own I really thought I got it and was excited to put it to use. I ended up with the perfect opportunity a few weeks later at work. We had some sample JSON data that was being used as an occasional fallback to show an example graph when customer data wasn’t available. However it was being loaded with a () => require('myData.json') statement. This was problematic because those large JSON files were being included in multiple other chunks instead of just one, and all these large files were being served up whether or not the sample data was even going to be used.

Now of course there’s multiple ways you can solve that issue, and I certainly thought about just throwing the JSON onto the server and making a request for it when it was needed, but I wanted to make the minimal amount of changes possible and thought, “Why don’t we just turn this into a dynamic import?” So I quickly changed the require into an import and immediately saw the chunks change drastically— it was beautiful. The sample data files became their own chunks and those other giant chunks became much smaller. But I was having trouble accessing the information from those files, and there were a couple different reasons for that, but the one I want to focus on is the one that was so difficult to find the answer for, maybe because it seems so obvious in hindsight.

JSON files don’t have a default export. And because of the other problems I was experiencing with resolving the promise in a legacy React component, I was at first dealing with a pending promise in the debugger instead of being able to just easily see what Webpack was returning. So I spent a good amount of time searching the internet to try to figure out if there’s a special way you need to deal with JSON files when you are dynamically importing them and couldn’t initially even find examples of anyone doing dynamic imports of JSON files.

So this was frustrating but I did eventually discover an example in an answer on StackOverflow that specifically showed what I needed and realized that this info needs to exist in more places on the internet. When you are dealing with a promise of a JSON file, you need to specifically be calling default on it, which is a key in the module object returned.

Examples of just capturing the data object:

import('myData.json').then(({default: myData}) => myData);

// or

import('myData.json').then(module => module.default);

Also worth noting that this isn’t the case if you’re using Parcel or dynamic imports outside of Webpack. In those cases the JSON will just be returned; which is part of why this was so confusing.

So I’m hoping this will help anyone else who gets confused if they’re new to dynamic imports with Webpack and trying to work with JSON.