DEV Community: Carin Chapman

I'm a JavaScript Developer who's learning Java

Carin Chapman — Fri, 08 Nov 2019 17:14:40 +0000

Despite their names, JavaScript and Java have less in common than you'd expect. Yes, they're both programming languages, and yes that of course means that they use a lot of the same underlying ideas (as do all programming languages), but when I recently started learning Java, I found a whole new class-based system that JavaScript doesn't use.

If you're familiar with the Object Oriented programming paradigm then you'll know that JavaScript kinda mimics classes sometimes. Like this for example, which is creating a constructor function for a puppy in pseudoclassical style:

const Puppy = function() { this.age = 0; this.legs = 4; this.food = "puppy kibble"; };

Puppy.prototype.eat = function(){ return this.food; }

window.Puppy = Puppy;

From there, you can make an adult dog that inherits all the properties of the puppy, and--through the powers of polymorphism--you can change/delete/add to those properties:

const Dog = function() { Puppy.call(this); this.age = 5; this.food = "big dog kibble" };

Dog.prototype = Object.create(Puppy.prototype); Dob.prototype.constructor = Dog;

window.Dog = Dog;

That's essentially the JavaScript way of creating pseudo-classes that inherit from constructor functions. You can even go on to make another "class" of "senior dogs" that inherits everything from puppy and/or dog and adds stuff like

this.food = "old fart kibble"

If that looks familiar to you, then good news! You pretty much already understand what classes are going to be like in Java.
Java hinges on classes. In this language, everything is a class and classes include constructors that are used to create object instances of a class. Here's a pretty stripped down version to show you what I mean:

public class Student { //these private variables will be used by the constructor, and //therefore by all instances of the objects created by the //constructor private int id; private String name; private int grade;

```//this is a student constructor, which creates a new student 
    //object (when called w/new keyword, compiler creates new 
    //instance)```

```public Student(int id, String name, int grade) {
    this.id = id;
    this.name = name;
    this.grade = grade;
}```

Here what we've done is to make a way for a Student object to exist. All student objects will have the properties that the constructor has: an id, a name, and a grade.
If we want the students to have teachers, we'll also have to create a teacher class with a teacher constructor to make teacher objects, like this:

public class Teacher { private int id; private String name;

```public Teacher(int id, String name) {
    this.id = id;
    this.name = name;
}```

Again, all the instances of a Teacher will be an object with the properties of id and name.
Now to make students and teachers, inside a Main class, we'd do something like this:

Student Billy = new Student(1, "Billy", 12); Student Sam = new Student(2, "Sam", 4);

Teacher Carin = new Teacher(1, "Carin"); Teacher Matt = new Teacher(2, "Matt");

Notice there that we're passing in values for each of the parameters we set up in the constructor function (e.g. id, name, and grade for the students or id and name for the teachers).

This is the beginning of the basics of how class works in Java, and how it's sounds similar, but is oh-so-different than the pseudo-classes in JavaScript.

Bourbon Street Bartender Adventure

Carin Chapman — Sun, 20 Oct 2019 18:26:25 +0000

GeoJSON data is here (and there. And also over there.) to stay.

It is data that takes geometry and geography and melds them together in a beautiful harmony that can make your data sing for your users (in case you missed it, that was a class A pun).

As data grows bigger and bigger, we have to come up with equally bigger ways to manage the presentation of the data, and geoJSON data is one such solution. GeoJSON gives you a way to present data--and of course, especially geo data--in novel, more engaging, and more digestible ways. Consider this.

Fancy a slice of indistinguishable pie?

Nobody can look at that, and frankly nobody wants to. When faced with a ton of info, if we're not careful, we'll end up with a slop of a mess of a chart/graph/etc that no one will ever take the time to understand. As purveyors of info, it's our job to both give the people the info they want and to also give it them in a way that they'll find easy to digest.

Some people call me the digestif of data. (Some people call me Maurice.)

GeoJSON data to the rescue. Yes, you can use it for maps, but let's consider outside-the-box ways that we can use space, too. If, say, I wanted to present some information in an interesting way, even if that data didn't actually necessitate spatial analysis, using a map can still be super fun.
Plus, there are really quick and straightforward tools for using geospatial data. One of my most recent favs is Leaflet.

Leaflet is an open source, JavaScript library that's used to create mobile-friendly, interactive maps.

To start off with a simple map, you just grab these lines from Leaflet, and put them in in the head section of your HTML file:

<link rel="stylesheet" href="https://unpkg.com/leaflet@1.5.1/dist/leaflet.css"/>

<script src="https://unpkg.com/leaflet@1.5.1/dist/leaflet.js"></script>

Then add a div for your map. I'll include some styling here, to give a sense of how simple Leaflet can be, but of course in best practices, we'd have a CSS file where we implement all styling.

<div id="map" style="width: 1105px; height: 700px"></div>

Then finally, inside a script tag, I'll use this map from OpenStreetMap (sidenote: all the code from here out will be inside this one script tag in the HTML page). Notice the L.map in the code. The L is a way to reference Leaflet's library, and the .map is a Leaflet function; the [29.959053, -90.064704] is a latitude/longitude point that I want to use for the center of my map; and we'll call the map "bourbonBartender" which is short for, "A Night in the Life of a Bourbon Street Bartender."

const bourbonBartender = L.map('map', { center: [29.959053, -90.064704], zoom: 14 }); L.tileLayer('http://{s}.tile.osm.org/{z}/{x}/{y}.png', { attribution: '© OpenStreetMap' }).addTo(bourbonBartender);

After that simple code, ta-da, we have ourselves this map.

From there, let's add the first stop our Bourbon bartender will make, which is grabbing food on the way into work, since the shift lasts about 14 hours with no break, so you gotta eat something behind the bar with one hand while you open seven Bud Lites at the same time with the other hand (no joke. I've done this. And it always gets great tips.)
This is super simple in Leaflet. We just add a point on the map. Let's use a polygon, and give it a little style to make it stand out.

const dinner = L.polygon([ [29.955428, -90.070693], [29.956620, -90.069639], [29.956081, -90.068554] ], { color: 'turquoise', fillColor: 'blue', fillOpacity: 1 }).addTo(bourbonBartender);

To do this, we're using L.polygon which is of course really similar to L.map, and then we throw in a few lat/lngs to represent the area around Killer Poboys, where we're going to grab dinner to go. Inside the options object, that comes as the second argument in the polygon function, we have a ton of options. You can style all kinds of amazing ways in Leaflet to make your maps as singular and stylized as you'd like. I'm using turquoise and blue and a high fillOpacity to make it really stand out against the backdrop of the map.

Then, just to make it clear to the viewer why we're going to Killer Poboys, let's add a popup on click that gives a description of the location. Here's the super simple code for that.

dinner.bindPopup("You haven't lived until you've had the roasted cauliflower sandwich.")

And with that bindPopup attached to the name of the polygon, we get this

Next, we send our bartender to work. This time, instead of a polygon, we'll use a nice-sized circle around the bar where they work, since it's the place of most significance on our map. Most of the options for the circle are similar to the polygon, except that you can determine the size of the circle based on the radius.

const work = L.circle([29.959528, -90.064869], { color: 'turquoise', fillColor: 'blue', fillOpacity: 1, radius: 150 }).addTo(bourbonBartender);

For this spot on our map, let's add a popup with a little more info this time, in pictorial form, using Leaflet's icon functionality.

const actorPortrayal = L.icon({ iconUrl: 'https://encrypted-tbn0.gstatic.com/images? q=tbn:ANd9GcQZ0lL1CtsOCHO-Xl95NsrROf7Vo6NSuDdPbu_YfIurU560523n-g', iconSize: [125, 125], // size of the icon iconAnchor: [22, 94], // point of the icon which will correspond to marker's location popupAnchor: [-3, -76] // point from which the popup should open relative to the iconAnchor }); L.marker([29.959528, -90.064869], { icon: actorPortrayal }).addTo(bourbonBartender);

You can grab a URL of an image and make that your icon--in this case, we're using a wildly inaccurate actor portrayal of what being a bartender is like: note the distinct lack of customers' vomit on Tom Cruise's shirt, the absence of glaring, neon Miller Lite signage, and not a single drunk dude screaming "More cowbell!" at the band. Then use L.marker() to attach the icon to a spot inside our circle, and voila.

Finally, after our bartender gets off work around 2 or 3am, it is their turn to be a bar patron. So the last stop of the night will be at the go-to spot for a bartender fresh off work: Erin Rose, where everybody does know your name, and everybody else just got off work too, and the bartender Jeff will make sure no one hits on you because Lord knows that's about the last thing you want to deal with right now, and the bartender Rhiannon will keep your shot glass full of Jameson no matter how many times you empty it.

const afterWork = L.polygon([ [29.956405, -90.068105], [29.956854, -90.067648], [29.956245, -90.067468] ], { color: 'turquoise', fillColor: 'blue', fillOpacity: 0.5 }).addTo(bourbonBartender); afterWork.bindPopup("<br/><a href='https://www.youtube.com/watch?v=wq_BkebIa8g'>Erin Rose</a>")

This time we're adding a really cool popup feature which is a link to this Esquire video, where you can see Jeff (super awesome guy, amazing bartender) in action and Rhiannon in a few shots (not sure why Esquire didn't feature her too. Big oversight on their part there, as she is an incredible person and a bartender extraordinaire).

And with that in place our map looks like this:

That's very little code to get across a whole night of adventure. With Leaflet and OpenStreetMaps, it's quick and clear code that you can easily customize and detail. From here, you can get way deeper into making the maps even more complex and detailed.

Of course this is great for representing spatial data, but I think it's also a nifty way to get across all kinds of information that might otherwise just be a boring list or a chunk of text.
GeoJSON data and Leaflet give us the ability to turn info into an interactive experience for users in a novel way, and since it's so simple to use, I hope this basic intro to the concepts encourages you to give it a try.

Mark Your Turf

Carin Chapman — Sun, 13 Oct 2019 20:15:56 +0000

We need to get cozy with spatial data. So invite it over, light a fire, pour a glass of the good wine, and make space for...space.

Why share your good wine with it? Spatial data plays a big role in augmented reality, big data, and the desperate need to protect privacy and civil liberties in the age of drones, facial recognition registering and recording an individual's location, "crime cameras" (aka: Jeremy Bentham/Michel Foucault's Panopticon, come to unfortunate fruition), and the like. This kind of space isn't exactly the final frontier, but it is one of the newer landscapes we need to learn to navigate.

Here's some vocab to start us off:

GeoJSON: "a format for encoding a variety of geographic data structures" according to geojson.org. Or you could say it's a "geospatial data interchange format based on JavaScript Object Notation (JSON.

The GISt of it is (that's an amazing pun, that you'll get in just in a minute, when I tell you about GIS) geoJSON is a few data types, including Point, LineString, Polygon, MultiPoint, MultiLineString, and MultiPolygon, all used for doing geometry with geography. Those data types can be stored in objects that are called Feature objects, and Feature objects can be stored with other Feature objects in sets called FeatureCollection objects. All these things, of course, are based on JavaScript Object Notation (JSON), so if you've used JavaScript, they'll be super easy to embrace.

Here's an example of a geoJSON point, which is the barest-of-bones sort of data format:

That's pretty straightforward syntax. You just make it an object (because it's JSON), you give it a "type" (which defines whether it's going to be a single point in space, a line of connected points, a polygon shape made from the connections of lines between multiple points, or etc), and you give it some "coordinates" (which are latitude, longitude in my example, but the order of lat/lng or lng/lat depends on the context in which you're using the geoJSON), and that's it. You've got yourself a slick new geoJSON object.

It gets a little more complicated from there, but not too much. For example, you can make a "point" into a "Feature" if, say, that point represents something in the physical world, like "A place we should support":

In so doing, you add data about the spot on the map that your geoJSON point is referring to, and give the point some context.

GIS: this stands for "Geographic Information System," and it is "a framework for gathering, managing, and analyzing data...[and] organiz[ing] layers of information into visualizations...[to reveal] insights into data, such as patterns, relationships, and situations—helping users make smarter decisions," as per the folks at esri. (FYI esri is a really nifty platform for mapping analytics, and I'd love to explore it in more detail in a blog post another day.) Put more simply, it's a way to use info, like geoJSON data, to make meaning and put geography into a context that a user can experience, understand, appreciate.

Enough vocab. The cool stuff is how you can use geo spatial data. There's a whole slew of related software, platforms, and so. Some names you'll run across that are worth looking into include:
QGIS
PostGIS
Leaflet
And especially Tom MacWright's aptly named "awesome-geojson", which is a list of utilities on their Github (bless you, Tom. You're a life saver).

But the one I want to briefly touch on here is Turf.js which has come in really handy for me lately.
Turf.js is a pretty self-explanatory library of functions that will help you turn simple geoJSON objects into data you can use to create cool stuff. Specifically, I recently helped build an app that gets people safe routes in flash flood scenarios, and Turf.js was indispensable. Here's a bit of how/why:

In that snipped of code, as the comments point out, I used Turf.js to turn a simple set coordinates into a geoJSON object using turf.point(); surrounded that single point with a radius that turned the point into a polygon of space with turf.buffer(); then found a user the shortest safe path by naming the buffered polygon of space as an off-limits "obstacle" along the route using turf.shortestPath(). That gave me back some much needed data that I went on to use to construct flood-free routes for users.
Turf.js made it quick and easy to implement their functions, and besides the couple I'm showing you here, there a ton more that give you lots of power with your data, by supplying the algorithms you need, so you can focus on what it is you want to create.

There's so, so much more to explore and learn about geoJSON data, all of which is way beyond the scope of this little blurb. I hope, though, that this entices you to consider using the data in the future and looking into it more.

The Write Way to Code

Carin Chapman — Mon, 07 Oct 2019 03:06:01 +0000

Think of your coding like it was writing. Like writing-writing, as in: pretend you're back in high school, and you have a plucky, young English teacher, who just finished their Education degree, and they have a heart of gold and would cringe at such a cliche metaphor as that one I just wrote. They want you to push your creative limits and write a short story. But not a story as short as the one you'd like to write, which would be more akin to a non-existent story. Still, you're def hot for teacher, so you'll force out some story to appease them.
You set out to your task and at first, your wee mortal brain is all like

and you think you're gonna own this assignment. But then you open up Microsoft Word to start writing, and there's that blank screen and that damned, blinking Microsoft Word cursor just blinking and blinking and mocking you for getting no words written yet. Five minutes later, your poor little pathetic human brain is defeated. You reach into your sparse vocabulary (you probably didn't know the word "sparse" back then) and dig through your saved words, choose some at random, and write some straight-up bullshit, hoping that teacher will still think you're smart and charming and dazzling, which you're sure they do already. (They don't think any of things, btw.)
Teacher, though, gets your story, and says "how about you try to find a better word for 'beautiful' instead of using 'beautiful' ten times in a fifty word story?"
You're like, shit, there are other words for beautiful?! Since you don't know them, you go to a thesaurus, find the word 'pulchritudinous,' and think that sounds smart as hell, so you both save that word in your memory and put it into your story and give the story back to teacher. Teacher goes home with your story, downs five Jack-and-cokes just so they can stomach reading the revised versions of their students' stories, but then decides to watch RuPaul's Drag Race instead and just gives the whole class As because teacher is already jaded and angry.
That's just like coding.
Minus the teacher; plus one boss.
Coding goes like this. Boss says, "do this thing I want done," and you're like, okay, I can do that. You set up your server (which is like the brain here, passing info around, in between places) and you grab some data out of your database (which would be your vocabulary) and you put that data into the frontend for the client (which is like submitting your story). Then the client might be like, "I want you to get me ______" (fill in the blank with whatever your app delivers to the client) (which would be like your teacher telling you to get different words). You might be like, shit, I don't have that in ye olde database, so then you got to reach out to an API (which would be our thesaurus), grab some info from it, and yes of course you'll send that info back to your client (story), but first you might want to save it in your database (vocabulary). Voila. The flow chart of writing and coding. One in the same. Minus all the Jack-and-cokes. But maybe plus a few tumblers of single malt Scotch (no rocks, please) if the developer happens to be me.
Maybe an even more significant way that writing and coding are like BFFs is the overarching sentiment of imposter syndrome in both fields. All writers, no matter their accolades or achievements, doubt every single word they write. They never feel legitimate. They never believe they've done the thing and done it properly (unless they are one of those few and far between writes who are pompous, sexist, assholes and think they're hot-shit no matter what, but we don't talk about Junot Diaz unless we have to). Take for example Tennessee Williams who said, "I don't believe anyone ever suspects how completely unsure I am of my work and myself and what tortures of self-doubting the doubt of others has always given me.” Or Virginia Woolf who wrote, "Is the time coming when I can endure to read my own writing in print without blushing--shivering and wishing to take cover?"
No matter how far a writer progresses, they almost always experience some degree of imposter syndrome. Software development is much the same. Even people with plenty of experience can sometimes feel like they are just a crock and they're waiting for someone to find them out. In that vein, Neil Gaiman said (in his incredible commencement speech in 2012), "The first problem of any kind of even limited success is the unshakable conviction that you are getting away with something, and that any moment now they will discover you. It's Imposter Syndrome, something my wife Amanda christened the Fraud Police.

In my case, I was convinced that there would be a knock on the door, and a man with a clipboard (I don't know why he carried a clipboard, in my head, but he did) would be there, to tell me it was all over, and they had caught up with me, and now I would have to go and get a real job, one that didn't consist of making things up and writing them down, and reading books I wanted to read. And then I would go away quietly and get the kind of job where you don't have to make things up any more."

I think most people feel this. At most points in their life. But in writing and in software development, we tend to be more honest about the fact that we feel this. Perhaps that's because in both writing and coding, there is always something new to learn and projects are never "done," you just have to stop working on them. And then maybe come back and revise them later.
This dual nature of uncertainty--the constant influx of new information (be it a new frontend framework you need to learn or a new character you're creating in a story) and the insistent nagging that you'll never truly finish a job--can leave people feeling very unsure of themselves.
The important thing to know about this is

it's normal.
everyone else around you is feeling it too, even if they aren't talking about it.
it isn't true. You aren't an imposter. And you can do the work.

Thus concludes my pep talk for the day.
Stick in there, and don't let the empty page--of writing or coding--get you down. Just keep at it.

RESTful APIs: a Marriage (of metaphors)

Carin Chapman — Mon, 30 Sep 2019 04:40:06 +0000

APIs are more than just vaults of info you can pillage for your own apps (and let the count of all metaphors in this article begin with that sentence: metaphor 1). They are sometimes vaults of data, but saying an API is just a data source you can pull info from is like saying your Lamborghini is just a roof for your driveway (that's metaphor 2 because, yes, I'm counting similes as metaphors. I'm allowed to do that because
a) I taught English for a long time, and
b) I thought about writing "is akin to" instead of "is like" but that sounded too pompous. So, take that: metaphor 2).

API actually stands for "Application Program Interface," which sounds like a name for the way people have sex in Demolition Man (metaphor 3). But it actually means something much less weird and creepy. It indicates that there's a piece of software, and it has a way of talking to other software. In API terms, we call this a "contract" between the two pieces of software.

Lots of different kinds of software have contracts. Stuff you'd expect, like servers, but also things you wouldn't think about like the (totally unnecessary) tech in super fancy refrigerators, and the not-at-all-obtrusive little device I just plugged into my car today (for real) that apparently measures my speed and braking and etc to report back to my new car insurance company to tell them how good of a driver I am...which I'm not at all weirded out about. And obviously find totally normal. Obviously.

Anyway, these contracts between pieces of software include prewritten and well-structured protocols for requests and responses. So when one piece of software sends a request--in the correct and appropriate format, as prescribed by the contract--the other piece of software is expected to send a response in the appropriate and prescribed format that both pieces of software agreed to in advance. Which is what leads to our real whopper of a metaphor: APIs are just like marriages (meta-four).

It's like when you marry a guy, and sign a marriage contract, now he is like obligated to respond to all your requests with a well-formatted and appropriate "As you wish." Or if he doesn't understand what a transcendental film The Princess Bride is, he might just say "yes ma'am and/or sir."

With APIs, there are a lot of rules about how to format these requests/responses. Back in 2000, a dude named Roy Fielding wrote his dissertation on APIs (among other things) and pretty much set the rules of APIs in stone, a-la-Moses and the Ten Commandments (metaphor 5). He called these RESTful APIs (RESTful stands for REpresentational State Transfer). There's a lot of debate about what exactly the rules mean, which ones are mandatory and which ones are more like "don't jaywalk" rules (metaphor 6), and as technology changes, of course the rules around it change, but here's a two-cent break down of some of the currently most widely accepted rules about what your API has to do/not do in order to be considered a RESTful API:

Separate concerns between the front-end and the back-end. This just means keep your front-end UI business separate from your data storage, which will make your UI way more portable between different platforms. You can think of it as a mullet with "business in the front, party in the back," (metaphor 6) since of course the back-end is all-party-all-day for devs, while the front-end has gotta look professional and whatever for, ya know, the actual living, breathing people who will use the application.
Keep your back-end stateless. Every time the client sends a request to the server, that client damn well better give the server all the information necessary to understand the request, and absolutely cannot use any of the stored context on the server. This is because servers are selfish and greedy and proprietary. Just like Apple...(metaphor 7). Actually it's cause you wanna keep your server as lightweight as possible and because a server's job is to deal with data, not a client's current specs.
Just tell your client up front if you're going to cache their data or not. No need to be coy, Ms. Server. Just tell the client whether or not the data you're sending back to the request is cacheable.
But the whole API can be layered, which means the server can be a little bit coy. In other words, the server can take the request from the client, and then make a few requests of its own, to other APIs, and there can be a whole lot of other interactions the server is doing behind the client's back, before it finally returns a pristine, shiny new response to the client, all without the client knowing anything about the server's goings-on. In light of my previous metaphor about this being a marriage, I think this might now mean that servers are allowed to "layer" their marriage, by which I mean cheat on their spouse a whole lot (metaphor 8). Shame on you servers, shame.
Finally, RESTful APIs have a "uniform interface," which is kinda complicated but think of it mostly as meaning that all requests need to have the same sort of info and style every time, and the back end should never return any part of its schema (eg organization) in the responses it gives back. Also, if the server wants to be a real peach, it can include self-descriptive messages in its response.

That's about it for the super-mondo important rules of RESTful APIs. Follow those, and you'll have the API of your RESTful dreams. For now. Though it seems the day is coming when RESTful APIs might finally feel their marriage disintegrating, as they grow apart and realize they have different interests now (like GraphQL) and just really can't make it work anymore (metaphor 9). But until then, live it up you dirty, cheating servers, and keep the party alive.

Be a Pro: A Sequel Pro

Carin Chapman — Mon, 23 Sep 2019 05:32:43 +0000

I'm not ashamed to admit it: I love MySQL. I love the demanding, uptight raw MySQL queries and all their asinine, diva-esque demands. I love the coy error messages, which somehow deliver almost zero information whatsoever about the error while simultaneously making you feel like a straight-up dipshit for not already knowing what your error is.

I love all of this about MySQL because MySQL is just like me: a foul-tempered, arrogant, know-it-all, jerk. What's more, MySQL treats me the same way I treat my partner.

I, too, do things like tell my partner he's screwing up but refuse to tell him explicitly how he's doing so and leave it up to him to figure out (he should've already figured it out). I, too, make obnoxious, pedantic comments to him (he should parse their meaning himself). And I, too, make egregious demands about exactly how the towels must be folded and which of my clothes CANNOT go in the dryer (and no I do not care that the tag says it can go in the dryer, those pants are never to go in the dryer, thank you very much, sir).

I'm not sure why he stays with me.
I'm not sure why I stay with MySQL.
Which is why I decided to try Sequel Pro.

As the folks at Sequel Pro put it, the program is "a fast, easy-to-use Mac database management application for working with MySQL databases." Note here that this is just for Mac users. If you prefer a PC (as do I, actually) you should check out MySQL Workbench. But back to Mac-centric Sequel Pro. It's a really simple, intuitive program that's free and easy to download right here.

You can think of Sequel Pro as an oven mitt. Do you have to have it? No. But (and here, let's pretend for a second like I know how to cook things and have done something like "make a casserole" before in my life, which, ha, yeah right, I definitely have not done) when you're pulling a casserole out of the oven, it'll sure be a lot easier and more pleasant if you put that oven mitt on first to protect yourself from all the burns your oven/MySQL will expose you to if you handle it raw.

Sequel Pro steps in between you and MySQL and gives you a far more intuitive and simple way to do things like write queries, create and manage the relationships between data, and so on.
In fact, it's intuitive from the start. Once you download and open it, you'll see this screen

That's one of the least-intimidating coding-related pages I've ever seen. Which is great.
From there, if you click "connect," without entering any information in those blanks at all, Sequel Pro alerts you with this

Insufficient details provided to establish a connection. Please enter at least the hostname.

If you're a person like me (ignorant, unclear on what's going on here/there/anywhere, and just trying to fake it til I make it) then you'll probably be like, "huh, well, I don't know what my hostname is but I know every time I make a MySQL database, I just put 'localhost' as the host and 'root' as the user, so I'll try 'localhost' for the 'host' blank and 'root' for the 'username' blank." And you'll type that in, and then Sequel Pro will very kindly nudge you along with this crystal-clear message:

At this point, even if you don't recognize 127.0.0.1 for what it is, you'll probably be like, "127 sounds less weird than a socket, so shoot, gimme that one," and you will have chosen wisely young Padawan. Sequel Pro will open up to you like a daisy after a rain shower.

From there, you'll see that, like magic, Sequel Pro will already have access to all the MySQL databases you have on your machine. They'll be in the "Choose Database" dropdown in the top left-hand corner, as seen in the picture above.

Once you pick a database, you can open up any of the tables, and get a view sorta like this

Looka how clean that organization and structure is! No more struggling through viewing your tables in the terminal and/or writing half-mile-long queries to prettify the view of the contents of your table, just to make them legible. Now you can just double-click on a table and get that sweet symmetrical view. Notice how quickly you can identify the primary key. Notice that you have dropdown options for things like "type" of data, which helps avoid syntax errors that occur when you've typed VARCHAR 50 times already today.

Finally, one of my favorite parts is the "Indexes" section on the bottom which shows you the relationships between a table's primary key and foreign key(s) in a way that's so easy to understand from just a quick glance. Even better, if you navigate to the "Relations" screen, it gives a sweet layout of what the foreign keys are, what table they came from, and what their name and column are in this table. All of this makes dissecting MySQL tables and their relationships way easier.

Last thing I have to mention is that Sequel Pro will actually tell you what your errors are if you have any. If you haven't tinkered in MySQL too much, that might not sound like a huge deal, but once you've seen this error about 7 dozen times,

You have an error in your SQL syntax: check the manual that corresponds to your MySQL version for the right syntax to use near 'id int AUTO_INCREMENT PRIMARY KEY, setup varchar(250) NOT NULL,' at line 2

and you still have yet to see any "manual" for anything you've ever done with coding, you'll be ready for somebody to just tell you what your damn error is already.

I came to appreciate this feature about Sequel Pro recently when I had to import, into my MySQL database, a CSV file of 690 rows with about 15 columns. There was an error in the file, and I spent hours bogged down in MySQL, trying to guess about what it could be. As soon as I switched to using Sequel Pro, though (there's also really intuitive functionality for importing and exporting data), I imported the CSV file, wrote a query, and instantly got squiggle lines under a part of my query. Hovered over that part, and Sequel Pro just outright told me that I couldn't use "Dec" in a column name because it's a reserved keyword that's short for "decimal" in MySQL. Now, you'd think MySQL would be decent enough to alert me to that fact, but nooooo. It was all like, "I don't like you or the query you rode in on and I refuse to help either of you." Two minutes in Sequel Pro, and the problem was solved.

In short, despite the fact that I do still think MySQL is pretty much the best, Sequel Pro makes the data simpler to see/understand and it's boss at handling errors. I'm a huge proponent of knowing how to do things at their most basic level, before getting a safety net that will make everything easier, so I do still suggest learning raw MySQL first. But after that, download Sequel Pro and save yourself hours.
Also, please know that I don't actually treat my partner like shit. That was all just a joke to get my point across. But MySQL is legit that much of an asshole.

What's love (of coding) got to do with it?

Carin Chapman — Mon, 16 Sep 2019 02:50:26 +0000

Real talk: I don't like computers. I might even hate them sometimes. We didn't have one in my house until I was 15, and call me old-fashioned--or just plain old--but life felt pretty damn sweet and a lot slower before the known body of information was doubling, like, every two weeks (that's a blatantly made up non-fact). So why am I talking about or even doing any coding?

It's because coding is to computers like wine is to grapes. Except wine comes from grapes and coding doesn't come from computers, but that's not the point of my not-at-all-apt metaphor. The point is that you might hate grapes or you might think they're okay-ish, but if there's a day-old pastry at the bakery and it has grapes in it and it's 50% off, and you're unemployed because you're in a coding bootcamp, you'll buy that cheap, grape pastry and mostly enjoy it. But boy-howdy, you'd way rather have a glass of wine.

Just in case I lost you there (I know: I did. Sorry about that) the day-old grapes is computers. It'll do in a pinch and maybe it's useful, but it's not the best. On the other hand, the grape-related product, wine, is completely amazing. Grapes and wine (or computers and coding) are related to each other, but only one of them gets you tore up. And makes you look classy at the same time.

Coding relates to computers, but what I was shocked to find when I started learning to code is how unrelated it is. It isn't really about the machine. It's all about creativity, critical thinking and analysis, and flexibility.
Take this example. On a project I completed recently, I realized halfway through that I needed to save some information in my database (mySQL) that I hadn't anticipated needing to save. I opened up my file with the schema, put my fingers on the keyboard, nodded in anticipation of the super smart code that was about to pour out of me, then realized I had no idea where to start.

Something I didn't understand about coding at first is that there usually isn't a simple, single, straightforward answer about how to do something. There are as many ways to accomplish a task--like adding some info to a database--as there are people who can do the task. (Okay, maybe not quite that many ways, but you get the point.) So, with this task, I had to figure out a way to preserve some tags--which had previously been saved inside a table called "posts"-in a table of their own while also relating them back to their associated post (posts have tags attached to them, that a user chooses). My first idea was to add a table in my schema that looked like this:
CREATE TABLE tags (
tagId INT,
postId INT,
FOREIGN KEY (tagId)
REFERENCES tags(tagId),
FOREIGN KEY (postId),
REFERENCES posts(postId)
)
That's a one-to-one table, with one tagId for every one postId. But I didn't yet have a table just for tags, so I'd need to make another table, so I made this one:
CREATE TABLE tags (
tagId INT AUTO_INCREMENT,
tag1 varchar (15),
tag2 varchar (15),
tag3 varchar (15),
tag4 varchar (15),
tag5 varchar (15),
postId INT,
PRIMARY KEY (tagId),
FOREIGN KEY (postId)
REFERENCES posts(postId)
)
Ah-ha! I thought. I have mastered you, tags! I'd taken a many-to-many relationship (between tags and posts), split posts and tags up into two separate tables, then made a join table that created a one-to-one relationship between postId and tagId. Perfect.
Except it wasn't.
I talked to my colleague, who was managing front end for the project, and realized that this schema set-up would require us to overhaul about half of what we'd already written. The details of how/why are too esoteric (and frankly too boring) for this little blog post, so I'll spare you them, but suffice to say, I'd spent a not-inconsequential amount of time just trying to figure out how to solve my problem--because many coding problems don't have prewritten, obvious, immediate solutions--then a good bit of time actually implementing the solution I came up with, only to find that it wouldn't work after all.
I had to scrap it all, go back to square one, and start over with trying to find a solution that would better meet our needs. Ultimately, I went through a few more potential ideas, tried out a couple things, and ended up including tags inside the posts table, and had to write a slew of new functions to get info about the tags into the right spots.
So why does this matter? First, it's indicative of a typical pattern with coding. You encounter a problem for which there is no straightforward or prewritten solution. You troubleshoot the problem, figure out what you need to do, and then try to make an educated guess about the best way to tackle it. You give it a shot, maybe get lucky and have something that works on the first try, but likely you have to go back to the drawing board again and again.
All of that means coding is about being a flexible and creative problem solver. Which is what makes me love coding. It's fun to run into obstacles and logic my way through solving them. Every time I get past one, it's like I just beat Diamond on American Gladiators at jousting.
Coding is for people who can be comfortable with uncertainty and who want to forge a path of their own, instead of looking for one someone else already made. And those people have to be willing to let go of code they wrote if it won't work, be creative to come up with unexpected solutions, and adapt to their circumstances. Plus you have to Google shit all the time. Which is why sometimes I like computers.

MongoDB: Not your grandaddy's DBMS

Carin Chapman — Mon, 26 Aug 2019 04:37:40 +0000

MongoDB is a flexible, noSQL database management system that allows for changes with an alacrity that modern technology and web-frenzy demands. If an app needs to regularly keep up with a constantly fluctuating stream of data, more traditional, SQL DBMS sometimes won't cut it.
Don't get me wrong; SQL has a place and time. If, say, an organization has a predictable set of data it needs to track and a predictable way it need to track said data, a SQL DBMS is the ticket. With a SQL DBMS, tables are created in advance and are pretty rigid. You can't just pop into the DB and decide you're going to populate a new column in a jiff. You can do that...you'll just hate it and it won't happen in a jiff. Of if you need to fetch any data, you'll have to maneuver through what can sometimes be an esoteric minefield of "right joins" and obtuse selectors that lead you down a labyrinthine path of hell. Of course--as with anything new--if you stick with it, writing raw SQL queries get easier and easier over time.
On the other hand, MongoDB and other noSQL DBMS offer easily manipulated data and the language for fetching data feels way more simple because its query language is good old fashioned JavaScript. It also stores all your data in JSON-like objects, and who doesn't love the comfort of a recognizable and familiar object? Every time I use MongoDB, it's like the scene in Ratatouille when the food critic takes a bite and has a flash back to his childhood: all those objects and all that JavaScript brings me back to the first days of learning to code and gets me all misty eyed. Plus, comfortable developers = better code.
On top of all that, MongoDB does so much stuff for you. For instance, it automatically adds unique an _id field to all entries in documents. Do you need to add it yourself? No! Do you need to set primary keys and foreign keys and blah-blah-blah? No! Do you need to mess with messy rules like adding "auto-increment"? No! Using it is a simple, straightforward process that will feel natural. It even automatically creates a collection for you, after you use a model to create a document once, without you having to do the work yourself. (Although you can still choose to create the collection manually if you want.)
If you tack on the use of Mongoose, you've got a really straightforward and powerful tool for crafting, saving, querying, manipulating, and using your data.
All that said, it probably won't ever replace the use of a SQL database. A lot of bigger companies in fact use both an SQL and a noSQL database to manage their data. Some data after all will be stagnant and need to be organized in reliable ways that are set-in-stone and intentionally do not fluctuate. Other kinds of data will be loosey-goosey and need the flexibility of noSQL. Ultimately, it's good to be comfy with both and to know why and when to use one over the other.

AngularJS Directives

Carin Chapman — Mon, 19 Aug 2019 12:57:58 +0000

Are you asking "why AngularJS?"? It's true there are bunch of young, chic, versions of Angular walking around out there, in their hip clothes with their wrinkle-free faces and their not-at-all-grey hair. But don't mistake youth with beauty! Old(er) things can still be beautiful. And what's more, older things often paved the way for the new, young things who now flaunt their stuff, and those older things left a mark on the world. A mark you might have to deal with. Enter: legacy code.

Sometimes you're going to have to play by the old foggy's rules because the old foggy wrote the rulebook.
If you walk into a gig unprepared for that, you might find yourself under water with legacy code that you need to work on but don't know where to begin. Get cozy with the fundamentals of AngularJS, and

you'll be ready for any legacy code you run into.
you'll understand the progressive change of the framework over time and better understand how it works and how to use it now (a lot of stuff is similar/hasn't changed)
plus (added bonus for free!) you'll appreciate the new, young stuff way more, when you see what you don't have to do because the framework is so improved now.

AngularJS Directives are one part of AngularJS worth exploring.
The shorthand version of directives is that they are like tiny, little commands that start with 'ng' and give your HTML superpowers.
AngularJS comes loaded with a handful of these directives, out of the box, and ready for you to use, with really simple and straightforward syntax. You just insert them into the template section of any component, and let Angular do magic for you.
One super handy directive is the 'ng-repeat' which will loop over an iterable for you, like this:

When Angular's compiler sweeps through the DOM and finds that ng-repeat, like magic, it will know that means you want to loop through the array wherever you insert the variable "coffee" into a template. Pretty neat, huh?
There are lot of other directives like:

ng-app--auto-bootstraps the app when the page is loaded and names the div element that it's attached to as "the boss" of the page.
ng-model--binds the HTML value that it's attached to (e.g.'input') to the application data.
ng-switch--lets you show/hide HTML elements based on a condition.
ng-click--built in click-handler
ng-conroller--tells AngularJS this is your controller in the MVC.

There are lots more too. They're quick and easy ways to make your HTML do all the cool things you want it to do, without a lot of the hassle of using raw HTML or JS to do so. Well worth getting to know how they work in AngularJS and versions of Angular beyond.

Your Concerns: Keep em' Separated

Carin Chapman — Mon, 12 Aug 2019 11:59:17 +0000

The Offspring made a whole song about it, so you know it's important. You gotta keep your concerns separated in your code.

Sounds simple, right? In pseudocode, that would be something like: just, uh, track down each of your concerns, put them in separate corners of the room, and tell them sternly to "stay put." Maybe waggle your finger at them for emphasis.

A lot of people on the wonderfully wide web of the world will tell you that separation of concerns means things like, "Keep your HTML, CSS, and JavaScript separate." Other folks say, "Keep your business logic and your presentation logic separate" (which basically means: have one place where you keep code for stuff that appears on the application and another place for stuff that doesn't appear on the app and is for internal processes, like processing credit card payments or keeping up with employee hours). And then other people--who like to frustrate you with their subtlety--might say something like, "Make each piece of your code do one thing and one thing only," which sounds pretty unrealistic.

The fact of the matter is, the definition of separation of concerns varies wildly depending on who you're asking. But, there's hope! If we rethink ˆhowˆ we're thinking about this, we might find a more useful conclusion.

Let's tackle it like this:

what are "concerns"?
what's our goal with separating them?
how do we separate them to meet that goal?

The answer to number one is going to depend on what your project is. No easy way to give a cookie-cutter answer for this; your "concerns" are delineated by the nature of your specific probject. It might help to think about it in terms of number two: what's our goal with separating these concerns? Our primary goal, the reason for the season of separation, is that our tiny human brains can't hold a lot of info at the same time. Anyone who's ever tried to follow a string of logic through a dozen different files, all named similarly, with multiple functions using multiple callbacks (also all named similarly) knows that this kind of thinking is slippery. We want to separate the concerns to make it easier to follow the logic and think through what's happening--both for ourselves and for anyone else who might ever have to read or change our code later.

If we break up our concerns into smaller problems, our brains can more easily keep track of them. When you consider the problem from this angle, does it necessarily make the most sense to separate based on HTML, CSS, and JS? Maybe not. It might be more reasonable to isolate bits of logic into consumable chunks that try to answer just one problem at a time. (That sounds like it might be closer to what they mean by "Make each piece of your code do one thing and one thing only").

Another reason we separate concerns is so that if we need to change/fix/add to/delete any part of our application, we can just go to that one part and tinker with it, instead of having to mess with all the code and possibly inadvertently break something else we didn't even mean to touch. Again here, I'd suggest that if you, for instance, were tasked with adding something to an application, even if you had your HTML, CSS, and JS separate, you'd still have to visit all three to add your new feature. So maybe a better way to separate is to keep each functional element isolated in the code. Maybe even--dare I suggest it--have your JS and HTML a little mushed up, as in JSX in React?

My favorite reason for separation of concerns, though, and one that argues against everything I just said above, is that when tasks are separated into HTML, CSS, and JS, it lets people specialize and become experts in one area. If one team member is really good at CSS while another is cozy with JS, if those parts of the code are separate, they can divide the tasks, do what they're best at, and conquer all.

In the end, there isn't a clear answer for how to go about separating concerns, but it is clearly important to think about and to try to do. There are a lot of growing, changing, evolving ideas about it, and that's part of what keeps the job exciting.

What's Object.create? (Spoiler: it creates objects)

Carin Chapman — Sun, 04 Aug 2019 21:39:19 +0000

Object.create is the new(ish) new.

Even though it might look clunky compared to the sleek profile of the "new" keyword, Object.create is a method, that Douglas Crockford--everyone's favorite grumpy granddad of JavaScript--created to circumvent what he saw as problems with the "new" keyword.

Object.create() is a pretty straightforward method.
It takes one mandatory parameter and one that's optional (and that you should probably not use).

The first parameter is the object that you want to use as the "parent" object, from which your brand new, bouncing baby object will inherit its methods and properties.

const babyObj = Object.create(parentObj);

The second parameter essentially equates to Object.defineProperties. (If you're not familiar but want to be, check that out here. But all you really need to know is that this optional parameter lets you add properties to your new baby object, such as how this new babyObj below has a property of 'bad:idea' added on to it.)

const babyObj = Object.create(parentObj, { bad: {value: idea} })

The syntax in this second parameter is super clunky, though. So, real talk: don't use it. Just make your new baby object, and then use good old dot notation to add any new properties you want, after the object has been created.
And just like that, you have a brand new dependent babyObj who inherited all your (possibly flawed) properties.

From here, babyObj will go on to acquire new properties of its own that will make no sense to you and that you won't be able to access or understand.

It's like if your baby object grows up loving Run-D.M.C. because of course your baby inherited all your good taste in music, but then baby object starts listening to Post Malone and actually seems to enjoy that--which is a property that you, dear parent object, definitely do not have and that your baby object did not inherit from you.

In that case, you can't suddenly also listen to Post Malone and claim that as your own property. And you shouldn't try to because you will look really dumb, you'll embarrass your baby object, and the whole world will be like, "wow, that's definitely an error."

Just relax, hold on to your own properties, and watch your baby object move forward in the world, becoming a fully-fledged object of its own, with its own new properties that it might very well grow to regret some day and delete babyObj.postMalone. Your babyObj will still always have the properties you passed on to it.(Even though it could technically overwrite them with its own values, and probably will do so when its in college, but don't worry about that for now. Just enjoy your object being created in your own image.)

In other words, in JS terms, new instances of objects resulting from use of Object.create inherit all properties from the object that was used as the prototype. That means that if you try to access a property on the new object but that property doesn't exist on the new object, JavaScript, being the thoughtful sweetheart it is, will say, "Oh, that doesn't exist there, but I see that I can look up into that baby Object's prototype object, and boy-howdy, that property does exist on the parent/prototype object, so here ya go!" Baby object has access to all properties on parent object, as well as grandparent object, great-grandparent, great-great-grandparent, and so on. All the way up to the original Garden of Eden, capital 'O' Object.

Again, in JS terms, this means failed lookups on the instance of an object will fall up the chain of prototypal inheritance. Should the desired property be found anywhere up the line, the baby Object will have access to that property. But as with Post Malone in the example above, the older objects do not get to access the younger object's properties.

const parentObj = { haircut: "sensible", clothing: "typical"} const babyObj = Object.create(parentObj); babyObj.haircut; // "sensible"

Super important to note that the new instance of an object is a brand new object; is it not a copy of the prototype object that it came from, so if you change the parent/prototype object, the baby/new instance of an object will inherit those changes , but if you change the baby/new object, those changes will not impact the parent/prototype object.

babyObj.haircut = "tri-hawk with devil lock"; console.log(babyObj.haircut); // "tri-hawk with devil lock" console.log(parentObj.haircut); // "sensible"

Besides being used just to make new objects, Object.create really shows off its stuff when used, for instance, in a subclassing example, with pseudoclassical instantiation pattern, which demands that you explicitly set the prototype of all new instances of objects in order to get access to all the sweet properties and bomb-ass methods you set on your superclass constructor function.

Object.create solves some problems that existed with subclassing by making it super simple to connect our new subclass with the superclass via prototype. For this reason and more, Object.create is not to be overlooked.
Shiny new things are cool too, but next time you want to create a new object without all the work of rewriting methods and properties, keep Object.create in mind.