DEV Community: Cameron

Grayscaling my phone made the rest of the world more vibrant (literally)

Cameron — Thu, 12 Sep 2019 14:50:29 +0000

Recently I enabled an accessibility option to map "Toggle grayscale screen filter" to the triple tap of my iPhone's home button, and within a few dozen seconds, after acclimating to the change and finishing whatever it was I had needed to do on my phone, I set it down. I say this as someone who absent-mindedly swipes between home-screen panels and refreshes twitter and facebook even when I don't plan on reading whatever pops up.

I still picked it up easily when I needed to use it: to send a text; read an email; or respond to a twitter DM or slack message. I still easily used the map features, and still browsed instagram briefly (which looked far more artsy in coerced-b&w), but found myself almost always staying more on task and putting my phone down when I was done with that task.

Why does this happen?

On further experimentation, I've realized this is because, from a biological standpoint, your phone is usually packed with more vibrant colors than anything in your environment. Even bright magazine covers pale in comparison to the phone screen. The lizard-brain in us sees the iPhone's home screen covered in small, bite-size applications, all in tantalizingly vibrant colors, and thinks simultaneously "nutritious berries" and "poisonous animals", both things we have become evolutionarily primed to notice and maintain focus on.

After some time on your phone, the world seems to be dulled, and for good reason. Compared to your phone, the colors of the real world are much duller. They're lower contrast less saturated, and less clean.

Turning on the accessibility feature for black and white filtering flips this dynamic on its head. Suddenly, your eyes are easily drawn away from your phone. Like a newspaper, the act of looking away from it fills your eyes with comparatively high color and brightness. The innate draw of your phone becomes solely based on the information you can glean from it and the things you can do with it, not how instinctively interesting it is to look at.

Obviously using your phone is generally a pleasurable activity, and I'm not advocating for less phone usage. I'm largely pointing this out because it draws into stark attention how much color affects our enjoyment of an app, and how bright, vibrant colors can really draw us in to a device, or an app, or really anything. Color matters a lot; not just how we use it, but that we use it.

How to switch to a grayscale display

As much as I don't think phones are bad, I think they can get in the way when you're trying to enjoy a book or movie or game, or are trying to focus on something else. If you want to be less drawn in by your iPhone, or see this phenomenon for yourself, you can map your black-and-white screen filter to a triple-tap of the home button by:

1. Settings > General > Accessibility > Display Accomadations > 
Color Filters > toggle 'Grayscale'
2. Settings > General > Accessibility > Accessibility Shortcut > toggle 'Color Filters'

How do you handle many-to-many relationships in Mongo?

Cameron — Fri, 06 Sep 2019 14:35:09 +0000

Or is this not even a useful way of thinking in the NoSQL paradigm? Regardless, how would you go about mapping large amounts of users to large amounts of groups, or handling likes on posts, or handling tags?

I'm super curious to hear your thoughts!

Seeding Mongo with Realistic Records using Faker

Cameron — Thu, 05 Sep 2019 23:40:52 +0000

So you have your app basically up and running, with a working API, but the only data you have are the manual entries that you've added to the database yourself. You don't want to have to manually sign up as ten thousand different users each with their own several hundred related items (blog posts, todo lists, etc) to get an idea of how your app looks and works when it's operating at moderate scale.

Enter faker. Faker is a library designed to, in its own words, generate massive amounts of fake data. By connecting to our mongo database, we can upload tons of unique users and items.

Seeding a Mongo Database

First, install the two dependencies we'll be working with npm i -D faker mongodb lodash. Next, make a new file in your server folder, preferably in a subdirectory for scripts, called something like seed.js.

/* mySeedScript.js */
// require the necessary libraries
const faker = require("faker");
const MongoClient = require("mongodb").MongoClient;
const assert = require("assert");
const _ = require("lodash");
// Connection URL
const url = "mongodb://localhost:27017";

// Database Name
const dbName = "my_dev_database";

// Use connect method to connect to the server
MongoClient.connect(url, function(err, client) {
  assert.equal(null, err);

  const db = client.db(dbName);

  // get access to the relevant collections
  const usersCollection = db.collection("users");
  const postsCollection = db.collection("posts");
  // make a bunch of users
  let users = [];
  for (let i = 0; i < 5000; i += 1) {
    const firstName = faker.name.firstName();
    const lastName = faker.name.lastName();
    let newUser = {
      email: faker.internet.email(firstName, lastName),
      firstName,
      lastName,
      password: "password123"
    };
    users.push(newUser);

    // visual feedback always feels nice!
    console.log(newUser.email);
  }
  usersCollection.insertMany(users);

  // make a bunch of posts
  let posts = [];
  for (let i = 0; i < 5000; i += 1) {
    let newPost = {
      title: faker.lorem.words(7),
      body: faker.lorem.words(500),

      // use lodash to pick a random user as the author of this post
      author: _.sample(users),

      // use lodash to add a random subset of the users to this post
      likes: _.sampleSize(users, Math.round(Math.random * users.length)).map(
        user => user._id
      )
    };
    posts.push(newPost);

    // visual feedback again!
    console.log(newPost.title);
  }
  postsCollection.insertMany(posts);
  console.log("Database seeded! :)");
  client.close();
});

Other Databases

The best way to do this with other databases is to require the ORM or database connection you're using into the seed script and then use a combination of faker.js and the ORM to do the above. If there's interest, I'd be happy to write up an example!

What are your favorite ways to generate fake/testing data for your API? Let me know below!

On Style Variables

Cameron — Fri, 30 Aug 2019 17:03:53 +0000

I used to think that variables in stylesheets were there to make refactoring easier. What I never considered is that they encourage consistency: When you have 4 different spacing variables, you're much more likely to build out a site where the sizes and spacing of each element are much more internally and visually consistent.

The same goes for font sizes and colors. By limiting yourself only to a set of variables, you're much less likely to experience consistency erosion, where your site ends up having 40 different hex values for grays alone.

Bootstrap does this for you, but I've never seen anyone talk about why that feature of Bootstrap is helpful, or why it's a helpful feature of pre-processor design systems in general.

In Teams, Being Deliberate is More Important Than Being Skilled

Cameron — Fri, 30 Aug 2019 16:55:57 +0000

Don't just do something, stand there!
– Pragmatic Thinking & Learning, by Andy Hunt

It's easy to want to rush into a feature or ticket that you get at work. The building is the gratifying part, and doesn't force you to think too hard about it.

But I deeply encourage you to spend the first 15 minutes of your work on a ticket – every ticket – analyzing it. Your goal in those 15 minutes is to answer as many questions about unspecified requirements as possible. Say you're tasked with building a search bar. At first glance you think, this'll be easy! It'll only take 30min or so, max.

But take the time to break it down. At my job, for instance, you need to think about:

What forms of input will this text search input accept?
What is the backend expecting? What form will the results be in?
Is it going to be possible to type in the bar while results are loading? Is there going to be any type of loading
What does the application state need to look like for this?
- Actions?
- Reducers?
- Types?
Does something like this already exist in the style guide / component library / app in general? Should these be used as guidance?
What will testing look like for this search bar, if testing makes sense for it?
Will there be a need for this search bar in other places in the app? If so, should I make it a reusable component?

15 minutes might not be enough time to answer all these questions, but it's enough time to get yourself thinking. If it takes longer than 15 minutes, by all means take more time!

By asking these questions ahead of time, you're able to write the cleanest possible code, and save the most time re-writing old code.

There are a few mental barriers to this desired behavior:

You have to bother your coworkers, your PM, your designer.

Take it from me, a person with terrible social anxiety: your PMs and designers love to hear feedback. They get anxious when they don't. Feedback on a half-baked or misled feature spec helps prevent disaster and shows your attention to detail, a skill which is extremely desirable in this field.

It's not gratifying in the same way as coding is. You're not seeing your output appear before you.

Think about this prep time as investment in your future code quality and speed. By preparing now, you're more likely to:

a) Give a better estimate on how long the ticket will take
b) Waste less time working towards a dead end as a new part of the spec comes into focus
c) Get all of your question asking out of the way so you're not blocked by waiting for an answer during a high-productivity moment later on.

It requires honing a different skill than raw coding, which can feel like a distraction.

As mentioned above, being able to think abstractly about a ticket and identify what things the spec is missing can feel sluggish and useless at first, but other people really appreciate it. A programmer with an eye for design and product is a programmer to be reckoned with. It'll enable you to move further and faster in your career.

Additional Benefits

Engaging in dialogue with your PM and designer more often will help improve the quality of their specs and mockups too, as they gain a better understanding of what's feasible versus nearly impossible as an engineer, and why a slight change in spec on, for example, a form, can change the total dev time by hours, if not days.

Experts and Interlopers

Cameron — Mon, 19 Aug 2019 17:39:47 +0000

Experts give a lot of value to their team. They get a ton done, they know things inside and out, and they can operate well within the system. They're great to consult with questions. They're good at building things quickly and in a stable manner.

Interlopers give a lot of value to their team. Because they're coming in from the outside, they're a font of new ideas that can drastically improve team processes, practices, and standards. They have no attachment to the status quo. They bring in smart ideas from other fields at a higher rate. They stoke revolution.

There's a reason revolutions are most common in countries with high numbers of unemployed teenagers.

Experts, despite their skills, have indeed drunk the Kool Aid. They're indoctrinated into the status quo, and it takes additional, rarer skills for an expert to see outside of the bubble in which they function so effectively.

I guess the takeaway here is that it's important for you to have experts and interlopers on your team. Those that preserve the status quo, that teach the old ways, and that know their way around the system, and those that can bring new revolutionary ideas to your team.

And the even bigger, more difficult-but-worth-it goal, might be to become and expert while still retaining that interloper spirit, never getting too comfortable with the way things are while still understanding how they work.

Decrease Your Time-to-First-Success

Cameron — Thu, 11 Jul 2019 17:06:59 +0000

Start with the smallest possible goal when learning something new.

When you're learning music theory, make it a priority to write a tiny jingle consisting of just a melody. Make a lot of these! Consider them complete when the melody is finished.

When you're learning game design, try using a game with a level design feature, or design modded levels / steam workshop things for a game you like.

When you're learning to code, spend some time creating static webpages on a LAMP setup before doing anything else.

Your ability to stay engaged with the development of a skill might largely be governed by time-to-first-success. The shorter that time, the more quickly you get hooked in a positive feedback loop. And I don't mean build something like this as part of turning it into something bigger. I mean that the small thing you're trying to build should function as the MVP. When you've finished it, you start a new project, and can feel a sense of accomplishment from finishing something meaningful to you, no matter how small.

Just Ship It

Cameron — Tue, 09 Apr 2019 16:47:43 +0000

If you're like me, you've worked on a lot of side projects where your enthusiasm has waned over time as you realize that it's not as niche-filling, interesting, or commercially viable as you originally hoped. I tend to experience this at the 70%-to-MVP mark, and then the project becomes just another directory I move into my archives folder.

If you don't have an already-extensive portfolio to show to interviewers or clients, just ship it! Having something is better than having nothing, and you're likely undervaluing the quality of your work. Plus, having deployment experience is incredibly valuable, and being able to DIY your way through the development, implementation, and deployment of a product, even if it's not up to your standards, is a huge confidence-booster!

I've also learned that deploying half-built projects gives me more incentive to work on them (as does publishing half-finished text posts that I can edit over time). It gets you over the hump of self-consciousness and you get something to show for it!

Just ship it!

Dev.to is the Perfect Platform for Mild-Effort Posting

Cameron — Tue, 09 Apr 2019 16:34:49 +0000

Wordpress, blogspot, ghost, and analogous blogging platforms have always felt to me much more metered, where everything you write is assumed to be drafted and carefully considered. Twitter has decent support for effort-posting but it feels like a hack (drafting threads specifically), and the good writing that comes out of Twitter seems like it exists despite Twitter's design, not because of it. Facebook has the obvious limitation of mostly being an IRL social network, with only mild support for long-form content (FB notes are extremely dead, and long-form content exists behind several read-mores, mixed in with your old high-school friends' selfies).

Dev.to perfectly bridges this gap: it offers a great interface for writing long-form content, while still retaining the trappings of an informal social network. Writing here also feels relatively protected, and not quite as public as writing in other places, due to the cozy community vibes it gives off.

I imagine that writing here will be a perfect place to test-drive ideas for essays and longer posts and to interact with other people putting a similar amount of effort into their writing: enough that it's substantial, but not so much that it's perfectly polished.

All this being said, maybe it's just the monospace font for article drafts?

Building My Own Markdown Compiler (1/?)

Cameron — Mon, 08 Apr 2019 15:52:57 +0000

After spending a lot of time on gwern.net which was written in Haskell, and reading Matthew Butterick's e-books, which were written in a markup lang built in Racket, I've decided that there are certain custom features I want from Markdown for personal website reasons that aren't provided in the vanilla spec. So, as is the novice dev way a lot of the time, I decided it'd be a fun learning experience to write my own website compiler. I'm currently reading Realm of Racket to get acquainted with the language, and plan on reading Beautiful Racket (by Butterick) afterwards, as trying to read the latter without some sort of primer or foundational knowledge was a little dry and overwhelming. I also think it's just much easier for me to read on my Kindle than it is to internalize the same info through a computer screen.

In the spirit of Realm of Racket, I've decided to chronicle my adventures here, and keep a log of the things that I enjoyed, as well as the things that slowed me down or acted as obstacles.

Et cetera:

Large exponents (e.g. 50 ^ 50) are calculated flawlessly in Racket for reasons I don't yet understand, which is immensely neat.
I think learning Racket could be a great intro into learning Clojure, which I also want to do.

Underrepresented Ideas in Coding Pedagogy

Cameron — Mon, 08 Apr 2019 15:40:38 +0000

Approaching coding as literacy

As many people have remarked (especially in this twitter thread), teaching people to read code before writing it could be a way forward for many CS students. Having students work through coding literacy problems during class would not only prepare them for certain kinds of interviews, but also establish a healthy paradigm of reading existing code that might prevent things like "not invented here" syndrome and a desire to scrap existing contributions to a project and re-write it all yourself.

Providing optional curricular pathways to match people's optimal learning strategies

Different people learn in different ways. I didn't really understand functions in programming until I understood that they were (ideally, and ignoring side-effects) equivalent to functions in math (i.e. that they were a mapping). Lesswrong's Screwtape wrote a great essay about why presenting the same concept in a variety of ways is important and effective.

Weaker Ideas

Learning functional programming as part of the core curriculum

I wish I had been exposed more to functional programming from the beginning! We touch on recursion in school, and I feel comfortable writing my own tree traversal functions, but outside of that it was hardly used. For example, I wonder why LISPs aren't taught as a core programming family alongside the normal ALGOL languages (C, Ruby, Python, Java, Javascript, etc).

Encouraging students to write tutorials based off what they learn

It would give students experience with real writing that other real humans might read (versus things only your TA will read), and help you internalize what you've learned in a class.

Redesign of class structure

I learned far more in intensive classes that only took a few weeks but occupied all my class time than I did in semester-long classes that only met for a few hours per week. Juggling 5 disparate classes becomes a meta-task of figuring out how to do just enough work in each to stay afloat, because you don't have the time or energy to fully devote yourself to more than one or two courses at a time.

Having one class at a time (with breaks frequently throughout the day) means you can really invest yourself mentally and emotionally into the material, and it prepares you much more for most jobs.

More lab time

The only way you can guarantee that a student is learning something is by giving them time in a space where they have to be working on it. As a recent grad, I always felt I learned much more quickly in a lab, with access to a TA or two, than I did on my own or in lecture. I also got work done at a much faster rate.