I’ve been pushing myself to use more advanced react patterns and new features from React 16+. Here’s a cheat sheet I made to help me remember how to implement react context!
React context is a new tool to manage shared state in your app help avoid repetitive “prop drilling”. You can read more about it here!
Inspired by Julia Evans and other wonderful code cartoonists, I have written my first programming zine! Check it out here: How to Deploy Your Personal Site Without Wanting to Scream
I just got back to my apartment after spending two days at the Web Animation Workshop in Portland! It was my first tech conference, and I am still feeling inspired from it. I can’t wait to start using what I’ve learned.
Instead of writing one long piece at the end, I decided to instead capture my thoughts throughout the experience. Every couple of hours I made a note of what I was doing and how I was feeling about it. Here it is!
In my hotel room, reading up on svg coordinate systems and downloading a markdown note-taking app so that I can be prepared for the workshop! About to walk over in a few. I’ve already explored the city a bit and found Alchemy Code Lab, where the workshop will be taking place. I’m still on NEw York time.
Learning about how Disney’s 12 principles of animation are applicable to modern UI design. Love all the examples! Unfortunately some technical issues with some of the videos, which are important for talking about animation.
In the past 20 minutes I realized at least 3 ways to make my site better. For me, the sections on continuity and choreography have been the most effective so far!
Feeling very inspired. I know that this is just the tip of the iceberg in terms of UX design, but I already feel like I have learned so much. I feel confident that some of these tips would improve conversion rates on my site by keeping users more engaged. Some of the choices I have unknowingly made might actually be hurting.
We are getting tips on how to get our companies to buy into the fact that animations are important – so glad they addressed this! Main takeaway: create buy-in by tackling something simple first and doing it well, create simple prototypes that get the point across.
Just had lunch and a nice conversation with some other bootcamp grads. Just in time, the jet lag was starting to hit, but I’m feeling excited for the rest of the day!
Overview of CSS animations has been a bit of a review for me – going over basics of transitions and key frame animations, which I have been using at work. Excited to move into more advanced topics later.
Fun mini-project animating a robot https://codepen.io/galencorey/pen/RLrjKO?editors=1100
Annnd on the flip side, the lecture on GSAP (a JavaScript library for animations) is seeming incredible fast and complicated. I’m also not totally sure it is something I can apply to my current work, although it definitely a very powerful tool.
Feeling better rested and very excited to learn about how to do SVG animations and animate with React! I am still rereading that article about SVG coordinates from yesterday, it’s pretty complex.
Having lots of fun playing around with GSAP animations and seeing what can be done. One of the speakers, Sarah Drasner, is showing us her work and it’s absolutely incredible!
I can’t believe the woman who wrote the actual book on SVG animations is helping me animate a bouncing ball.
Itching to get started on an SVG animation for the loading screen for our site. I have a renewed sense of how code can be both extremely creative and extremely technical. Creating an animation requires a totally different way of thinking.
Keep getting carried away working on the mini-projects, wish there was more time to work on them.
Gahh finally react. I keep getting overwhelmed with how much I want to do.
I wonder if my boss will let me use any of these libraries.
Also, why am I so stuck on how I can use this for work and not how I can use this for fun? The good thing about what I am learning now is that it can be applied to both.
Things have come full circle, as they tend to. A year ago I was enrolled in Grace Hopper, and now I am teaching a coding summer camp for high school girls. I am one week into the two week program, and so far it has been an amazing experience. The girls all come from different schools and different backgrounds, and all started the program as complete strangers to coding and computers in general – on the first day more than half of them identified as ‘not a computer person’. Already, after only 5 days of work, they have created 3 projects that they feel extremely proud of, and have developed a basic understanding of HTML, CSS, JQuery, JavaScript, the command line, and git. I am very excited to see what the next weeks bring.
I have been using Codecademy as a teaching tool and it has been extremely effective. It allows students to move at their own pace through a curriculum and try things with straightforward examples. It makes a very good complement to the “real-life” coding projects that they work on in pairs, allowing them to apply the knowledge they have gained to a project that they have to see from start to finish.
The girls are excited to next week begin working on a longer project of their own choosing. The organization that runs the summer camp feels strongly that code can be used as a tool for social change, so I am encouraging the girls to choose a project based on an issue that they care about. I am excited to see what they come up with.
Hard to believe, but a year ago today was my first day at Grace Hopper! I have now been employed as a developer for almost six months, and many of the things I struggled with as a student now seem completely natural to me. I have gained a much deeper knowledge of how to build web applications. I have also gained a much deeper sense of how much more there is in the world of computer science for me to learn.
It can be hard to find the time for independent learning, especially about things that aren’t directly relevant to my job, but I think that it is important to my growth as a developer. The next chapters of this blog will be focused on this broader exploration – as soon as I figure out what to explore.
I have now been a real, live full stack developer for over two months! I was lucky enough to find a position that used, essentially, the same stack taught at Grace Hopper. We use a MySQL database, and Express server on Node, and React on the front end. This has made my transition into the job pretty seamless, I was able to quickly understand the existing codebase and start working.
There are, however, a number of technologies that we use that I had either never heard of before, or never used before, that I have learned on the job
1. Flow:
Flow is a static type checker for JavaScript. What does this mean? Well, JavaScript is a dynamically typed programming language – in plain English, it doesn’t care how often you change the types of things. You can define a variable as a string and then reassign it as a number. A function can return a number sometimes, an object other times, and undefined the rest of the time. JavaScript doesn’t care.
Especially when you are just starting out, it’s great not to worry about type. However, Having strict typing (meaning, a variable or argument will always expect to be the same type, a function will always expect to return the same type) is a good way to catch errors before they happen. Flow essentially allows you to use JavaScript as a strictly typed language.
It works well with React, because you can use flow to specify what types of properties your component should receive. Then, if you try to render a component without those properies, Flow will error. This can be, in many cases, clearer and more efficient than writing tests. Once you beat the learning curve, flow is a great way to catch errors before they emerge.
2. Jest
Speaking of efficient react testing, we use Jest on the job. What sets Jest apart from other front-end testing frameworks is the ability to take “snapshots.” A Jest snapshot creates a separate file that contains the return value of a function at the time the snapshot was created. You can use this with a React component, capturing a stringified version of the HTML that the component renders. Then, in the future, if you accidentally change something in the snapshot, the test will fail. Of course, if you intentionally change something, it is easy to update the snapshot. Because much of the labor of writing React tests is just making sure everything renders correctly, this can save a lot of time – which, in turn, makes developers more likely to write tests.
3. Yarn
We use yarn instead of npm for dependency management. I’ll admit, I haven’t taken much time to learn about yarn, mostly because the switch to yarn has had almost no effect on my workflow. The commands for yarn are almost the same as for npm, i.e. you can just run `yarn install` instead of `npm install`. Your package.json looks the same. The only major difference, as I understand it, is that yarn is faster (or something)… seems cool.
4. Async functions
I can’t lie, I freaked out a little bit when I realized that the codebase at my job almost never used promises to handle asynchronous operations. Instead they use async functions, a feature of ES2017, the newest version of javascript.
Here’s what happens. If a function needs to do something asynchronous, you define it as an async function. Then, inside the function, you get a nifty keyword “await”, which basically says “wait for this async thing to happen and then give me the result as an actual useable value.” No more chaining thens, forgetting to return a promise, or fishing around for the actual value you want. I can’t say that I am yet an expert in async function syntax, but I tentatively have the feeling that this is the best solution that exists for async in JavaScript.
Above: the amount of work I have done on the website, compared to the amount of work two others had done before me.
My past month on the job, I have been helping to put the finishing touches on a website that was very nearly complete. My tasks were varied – add a hover state to a button here, block certain users from taking the test there. When I started work, it was with the expectation that the site would go live very soon, but it seemed every week we uncovered another thing that was not quite ready, and delayed the launch.
A week ago, the CTO declared with a defiant conviction, “we’re going live first thing Monday morning.” And this time, unlike the other times, we could all tell that it was actually going to happen.
Our whole team, not just the developers, started testing every edge case and making note of bugs. Suddenly, the site started to look very different. The flaws in things that we were used to seeing every day came to the surface. We worked through the weekend, and Monday morning, things were looking pretty good.
Then we tried to open the site on an iPhone, and several new and deeply inexplicable errors emerged. We powered through the rest of the day. I went home unsure what would happen, and when I checked slack once I got off the train, there was a message saying “we’re going to hold off until tomorrow morning.”
We finally launched Tuesday evening. It was exciting to see the site go live (and we’ve already had our first orders come in), but it was also a bit daunting – what would be the first thing to go wrong? Would my code stand up to actual users, and potentially hundreds of them per day?
We shall see…
So I have officially done what I set out to do – I have become a professional software developer. I started work this Wednesday at a small start up in the city. The company has about 15 employees as of now, and is located on half of a floor that is being rented out by a design company with too much space. It has a decidedly modern feel. The walls, furniture, and fixtures are all white and cyan and frosted glass. Everyone sits together at a large white table, and the wall is lined with a few standing desks that I occasionally take advantage of. The kitchen, I am told, once was stocked with snacks, but, tragically, this is no longer the case. Still, there is a Keurig machine and a nice assortment of Tazo teas, so it’s hard to complain.
There wasn’t much of an onboarding procedure. They bought me breakfast on my first day, and everyone stood around and introduced themselves to me. I received my new macbook pro, 15 inches, space gray. Within an hour, I was working on my first assignment, which was to add my name and picture to the company website. After that, I was given my second assignment, which was to build out an actual feature for the website.
I started to get fatigued pretty quickly. When I was a student at Grace Hopper, I got used to focusing on code all day long, but I slipped up a little during the fellowship when I didn’t have urgent projects to work on every day. So my first full day of coding took a lot out of me. I managed to get the feature working by the end of the day, but as soon as I got on the train home I immediately realized several things that were missing from my work. I spent, essentially, the next two days refactoring and polishing the feature. I also wrote tests for it and did some bug fixes throughout the site.
I have been working closely with another female developer, which is great. She has worked extensively on website that I am working on, and has been a very good resource as I am getting started. I have mostly been using React, which I feel comfortable with, but we also use some new libraries that take some getting used to, so it’s good to be able to turn to the person next to me and ask a question when I need to.
The company I work at does a lot to be transparent, so I have also been attending meetings that are not at all technical in nature. It is a glimpse into a world that, up until now, I knew little to nothing about. Perhaps, within a few months, I’ll be able to say more about the process of startup funding, or the politics of telemedicine. For now though I’m just absorbing all that I can.
The job search… the big question mark at the end of every coding bootcamp.
“Will I really be able to get a job after this?”
“What does that 97% hiring rate that Fullstack Academy advertises really mean?”
My job search was postponed when I became a teaching fellow, so I was able to watch some of my former classmates go through it from a distance. Some of them were lucky and landed dream jobs within a few weeks. Others, the majority, I think, seemed to struggle more. The anticipation built.
I told myself that I would start my own job search on January 1st. This would give me 6 weeks before the end of my fellowship (and looming last paycheck). I procrastinated. I submitted my first job application on January 3rd. I received my first job offer on January 27th, and my second offer on February 1st. I accepted an offer on February 2nd. The whole thing was over and done with in less than a month.
This was, obviously, a favorable outcome. Do I know what I did to make this happen? No. I must have done something right, but other things I almost certainly did wrong. Here’s a bulleted list (yay!) of facts about my job search. I think it serves as a nice contrast to some rather frantic posts I have read about the post-bootcamp job search, although I do not propose that any of these things are “lessons” or in any way indicative of what is typical or will work.
In any case, today is my second to last day of work at Grace Hopper, and I start my next job next Wednesday. I am very excited to get started!
This holiday season, I discovered a new favorite tradition: Advent of Code. It’s an online advent calendar with two new coding challenges each day. On day 4, I ran into a perplexing problem. I tested my code in every way I could think of, and I was pretty darn sure it worked, but I couldn’t get the right answer.
Why couldn’t I? Well, to find out, let’s flash back a couple months. I was answering questions for one of my first workshops as a teaching fellow. The students were writing two different sorting algorithms: merge sort and bubble sort. There are a number of sorting algorithms out there with different efficiencies, and learning to write them is a good way to build fundamental programming skills. Most developers rarely have to write these algorithms themselves, however, because languages like JavaScript have a built in sorting function. The last question I was asked on that workshop was, “So… under the hood, which algorithm does the JavaScript sort function use?”
“Interesting, ” I said, “let me look that up.”
It turns out that, like many things in JavaScript, the answer is “it depends.” It depends on the engine that JavaScript is running on (in most cases, this is determined by which browser you are using). So, in short, different browsers will interpret the line array.sort() in different ways.
Fast forward a month. It turns out that my solution for day 4 of Advent of Code relied on JavaScript’s sorting function. And my solution made an assumption about that function: that it would use a stable sorting algorithm.
A stable sorting algorithm will take two elements that it sees as equivalent and leave them in the order that it found them. An unstable sorting algorithm makes no such promises. It could leave them in the same order, or it could swap them.
A lot of the time, that makes no difference whatsoever. For example, let’s say you want to sort the following array:
[5, 3, 2, 3, 1, 4, 7]
It doesn’t really matter which 3 comes first in the solution – you will get the same answer either way. An unstable sorting algorithm will do perfectly fine here. But let’s consider a situation in which you are sorting objects instead of numbers. These objects have both a name and an age property, and you want to sort by age.
[{name: 'bob', age: 3}, {name: 'alice', age: 5 }, {name: 'willow', age: 3}]
In this example, an unstable sorting algorithm might tell you Bob comes first, or it might tell you Willow comes first. A stable sorting algorithm will always say that Bob comes first.
And sometimes that matters, especially when you are trying to sort by two keys. For example, if you wanted to sort the above array by age and then alphabetically by name, you would need a stable sorting algorithm. This is essentially what I was doing in day 4 of Advent of Code.
So here’s the thing. Most browsers don’t consistently use a stable sorting algorithm. I was running my code in Node.js, which uses Chrome’s V8 engine, which does not use stable sorting. As soon as I ran my code in Firefox, I was able to get the correct solution. Magic!
Galen E. Corey 