DEV Community: Ben Sullivan

Inline and External CSS: Readability and Performance in React

Ben Sullivan — Fri, 08 May 2020 15:32:13 +0000

Inline CSS gives developers a way to see their styling in the same place as their functionality. As ridiculous as it is, being able to minimize the number of open files in an IDE is a way to improve developer's quality of life. Adding more windows, files, and complexity is a form of poor performance. The few seconds of context shifting between files or programming languages slows down the amount of code a programmer can write. It adds to the amount of unhappiness they experience as they write. So the solution is write your CSS inline even at the expense of some performance.

External CSS allows some performance gains. It's a way to keep your file lengths lower and compartmentalized. If your focus is to cordon off portions of your code in such a way that each file does a single thing or you need to keep styling away from functionality External is the way to go.

Libraries are Killing Me

Ben Sullivan — Fri, 08 May 2020 14:34:58 +0000

Something that's been infuriating is adding libraries to any project that I've been working on. NPM and Ruby make it all to easy to add someone else's knowledge and bad habits to your projects. I've used a few great libraries before, but recently I used a library that allowed me to raise the technical floor of my project, but also lowered the ceiling of what I could include as a feature.

Google Maps is a pretty decent API. It's easy to get started with and has some very deep features to play around with. A recent project I started working on had a strict time limit that did not allow me to learn how to build out my own implementation of those APIs in React. Enter libraries. I was up and running in less than a day. Everything was going smoothly until I needed to get into deeper parts of the API. The great library I was using started to fight me.

This is the most frustrating impotent feeling of learning something new. I could make my own tools, but it would take far too long. Since the goal is to complete a project, to ship, I've had to cobble together other code bases into a configuration I want. Sometimes those pieces don't quite exactly fit and I have to tape them together. If I had more skill I could build my own bespoke tools, but that would take me far too long. It's a complete mess and the compromise I've come to is: "I'll come back later."

Modeling Location and User Data with an Unknown End State

Ben Sullivan — Fri, 08 May 2020 13:09:19 +0000

I've spent a good amount of time thinking about this project's end state. It's been one of those ideas that has always felt a little out of reach. I filed it away to pull back out when I had the skill. The quick pitch is a personal journal of local places that you've been with a way to share that journal with your friends. Since this is a boot camp project, it's pretty tightly time constricted. Since software development cycles are pretty notoriously longer than expected I planned to roll out features in order of importance. While that's the moral of the story the journey can be just as instructive.

I had the idea to build out the back-end from most to least important feature and then move on to the next. Hopefully this would cut down on the amount of time I would take to plan out new features. To begin, the two main features, location tracking and sharing, wouldn't take too many models, just Users, some way for them to self join, and a many to many relationship between Users and Places. This phase was completed before any front end work started.

After those features were completed I started working on the user facing features along with building the user interface. I planned to all users to make Lists to share with other users. Lists would be a simple join table between Users and Places. Users would be able to create lists of places and decided whether to share those lists with other users. While Lists are implemented on the back end, they aren't implemented on the front-end. I'll get into it in another blog post, but I ended up focusing on the front-end a little more than the back-end which caused a decent amount of back-end code to be unused at the deadline, but available for future implementation.

Filtering was the last planned feature. Unlike Lists, only the models and relations were created for filtering. However, instead of focusing on a different portion of the app at the expense of this one, I almost completely phased this feature out in favor of working on bounding the map and locations that render on it dependent on User's locations. Unfortunately, I chose to focus on getting the core functionality working as smoothly as possible at the cost of nonessential features. Not only did I move my focus away from inessentials, but this feature was stymied by the libraries I used. This is the one that hurt the most to kill. Interacting with a map can be difficult and ways to narrow a user's focus down to only what they want is important. I added a few niceties to the front-end that made the user experience better, but still it can be overwhelming to use a blank map when you have the entire world to choose from.

The back-end for this project was disappointingly simple. I think that most of the interesting features usually come from a complex and clever back-end. Making large queries based on validations and knowledge of structures in place look easy is skill set I would like to build upon. The better a database is designed the less you're supposed to notice it. To that end, at least, I think the early planning of the roll out of back-end features worked. I spent a very small amount of time working on the back-end because my planning allowed me to implement it and then essentially forget it. The monolithic design structure and waterfall approach to building features before I needed them would have saddled me with even more dead end features.

Duck (Typing) Farm Development

Ben Sullivan — Fri, 06 Mar 2020 17:14:57 +0000

As a light disclaimer, I am still working on adding duck typing to my skill set. As a result, this is a very silly way for me to gather my thoughts in one place. There are no examples or even code snippets, but abstract and ridiculous examples of patterns that help me when designing and writing code that could benefit from duck typing.

As an interpreted, dynamically typed language Ruby is built to make developers' lives as easy as possible. Unfortunately, this relies on the developer knowing and being willing to shift their habits to follow these best practices. This does not make your life easier in the short term. Developers being mortal and mostly human, have a hard time shifting their focus from short term solutions to generalizing their problem for others. It is far easier to say "My bird quacks and walks like a duck, so my bird is a duck. Future birds are someone else's problem." Besides you'll be at a different duck farm identifying different ducks in a few years. That's a hard habit to break, but it will make future developers less likely to hold grudges against you.

OOP lends itself to bad design habits by creating problems whose easiest solutions are concrete. An answer to a single case ships features now while creating extensibility problems later down the roadmap. Concrete code and knowing too much context about other objects are examples of temporary solutions. These create technical debt and while they are convenient now, result in difficult to change code bases with far reaching dependencies.

One of the marks of good design is trust. Concrete code trusts no duck. It wants very specific things in a very specific order. It interrogates every duck about all their duck habits in a set order. If a bird quacks when you ask them to waddle they won't pass your duck test. It's a very inefficient, error prone form of identification. As a duck farmer, when customer asks for a bird that waddles and you winnow by birds that also quack you lose out on getting rid of Steve the goose who always attacks you when you try and feed him. Duck typing allows for flexibility in implementation and request fulfillment. Focusing only on the specific request allows you to be more flexible when required.

Narrowing objects that can interact with each other in specific ways narrows your future choices by relying on too much context. Earlier we were relying on too much context when we knew that Steve waddled and is a feeding time terror. That 'and' is important. It is descriptive of Farmer who is strongly coupled to it's Duck and Geese objects. Duck typed code, unlike farming, should know as little about the objects as possible. 'And is a feeding time terror' is too much context. The bare minimum is exactly the amount we need to create something that is flexible. The chain of trust should extend from the Customer to the Farmer to the Thing that Waddles.

Duck typing allows you to expand your software duck farm easier by requiring the least amounts of change to fulfill the requirements of it's application.

If you need a more technical, less silly discussion of duck typing Sandi Metz's Practical Object-Oriented Design book, specifically chapter 5, contains very helpful examples and a more technical look at Duck Typing.

Modeling a Swiss Tournament in a Relational Database

Ben Sullivan — Fri, 14 Feb 2020 05:14:18 +0000

Years after recovering from weekly trips to dingy, artificially and poorly lit shops full of cardboard worth more than its weight in gold, I still think about analyzing and modeling Magic: the Gathering tournaments. The dance of choosing the right deck followed by the scramble to borrow, buy, or rent cards for a tournament only to lose your first two rounds eliminating any hope of recouping your expenses, still has some nostalgic pull on me. One of my last tournaments ended in a final round loss that put me that single loss out of a money finish. That night, instead of celebrating during the 3-hour drive home from Denton, I had to pick myself up off of a cold sidewalk, toss my midnight Wendy's into the trash, fill my car with gas and load 4 more not small college dudes into a sedan. I had to wake up the next morning for my 8am Intro to Computer Science class technically that same morning. Those were the lengths I would go to scratch my competitive itch. There's still enough positive nostalgia to inspire projects.
Being relatively new to database design, I want to work through, step by step, an idea I've been thinking about since before the midnight Wendy's in Denton. Given perfect information about a Magic tournament, how would you model that information? That includes players, their matches, the tournament information, player deck lists, winners, etc. Storing that information isn't enough though, I want the structure to be generalize-able to other Swiss tournaments.
Let's construct some sort of helpful simpler example that we can use to model out the initial database. Let's say we have Rock-Paper-Scissors players who want to compete in the Rock-Paper-Scissors World Championship. The RPS League is starting out fresh and they have no prior tournaments, but they have a structure of tournaments through which players can qualify by winning a World Championship Qualifier that will then qualify the winning player for the World Championship. This gives us a lot of RPS players who want to play in a lot of tournaments. At its most simple a tournament is a collection of matches played by players with a winner and a loser. This yields a many-to-many relationship between Tournaments and Players and a semantic name for the join table! As of right now this is our model:

This looks pretty good so far! It's simple, but with a lot of useful information. I've also added a few columns that will be helpful later when I use this structure in my MtG tournaments. Don't worry too much about the column structure besides the foreign keys. Those are the most generalized relationships. I've included a rating in the Players table so they can look up their Elo once the system is fully built. They need to know when they're improving! This looks perfect for our RPS League. We can find players who played in tournaments before, check who won, and, if we wanted, see the highest rating player is.
This is a great high-level very general look at a tournament model, but let's get more granular. Let's move back to MtG and its specific needs. Players can bring their own custom decks made up of cards to tournaments. Or a Deck has many Cards. That's a relationship we can add to out database model.

That relationship looks good too! I need to caveat this relationship by stating that Decks and Cards is actually a many-to-many, but that's a little too granular for right now. Skipping that, let's figure out how to connect Decks to Players and Tournaments. For simplicity, we're going to say that a deck is only used once by a player, who can use many decks in many tournaments, in a specific tournament, that can have many decks. That's a long string of relationships, but it boils down pretty nicely.
A simple and naive approach to achieve this is to create a join between Players, Tournaments, and Decks. If you've ever played in an MtG tournament they give us a name for this table called Registration, it's pretty semantic and the relationship fits right in my head so let's use it. In the process you sign up for a tournament, list the cards in your deck, and add your name to the list. This was the end point of my knowledge for database creation, and I ended up pretty happy with the result. HOWEVER, after talking to someone with more knowledge than myself there's one more step and this isn't the final product. Here's my original finish point:

If you work with databases you'll notice that, while this would probably work for a simple application, this database is not normalized. There are a lot of extra points and information can be gotten in strange round about relational loops. We can fix that though. We can make it more simple.
Here's the final product. It's normalized, most data can be accessed via a single relational route, and all data is available through a single route. An optimization that could be implemented would be to only have a winner and loser foreign key in Matches instead of RegistrationID1, RegistrationID2, and Winner. Besides that I believe this is a 3NF database. If not feel free to let me know. Feedback can only help me learn.

Learning and relearning what I now know about databases has been fun. I've been drawn to larger data sets for their statistical significance, and the information that you can glean from trends in meta-games such as deck building in MtG. It scratches an itch that is close to and more satisfying than the itch to compete, the itch to collaborate and succeed.