DEV Community: Josh Hadik

How can you prepare for a job at Google?

Josh Hadik — Sat, 04 May 2019 21:20:20 +0000

There's a ton of articles and advice out there on how to prepare for a coding interview for companies like Facebook, Google, Netflix, etc.

This is great and extremely helpful for actually landing a job (even if it's not at one of those top tech companies.)

However, I don't think it's enough.

I don't know about you guys, but if I ever did land a job at Google or Facebook, I wouldn't want to feel like I got it just cause I was able to "hack" my way through the interview process.

I'd rather go in on my first day feeling prepared for whatever challenge "X" company throws my way, instead of feeling like I'm not cut out for the role and wondering how long it will take for them to realize the interview was just a fluke.

With that in mind, what's your best advice on how to prepare for an actual programming job and not just the programming interview.

I used Google in the title as an example, but I want to keep this discussion as open as possible, so I'd love to hear your advice even if you don't work at one of the FANG companies.

What are the best alternatives to Adobe assets?

Josh Hadik — Fri, 15 Mar 2019 21:26:14 +0000

Adobe used to have a really cool feature on Creative Cloud called Adobe assets, which worked almost seamlessly with Adobe XD. Basically it provided a quick and easy UI to download icons while designing a wireframe.

So If I was sketching the layout for an iPhone app, and I wanted to add a home icon to the the home tab in the design, I could easily search for home icons, download my favorite one, drag it into the XD file, and position it in home tab section. And all of this could be done for free right from the toolbar at the top of my Mac.

It was such a perfect UX for downloading icons and adding them to a wireframe, and it made the task of designing apps and websites so much simpler.

Unfortunately, Adobe got rid of this feature. I'm not sure why, and I'm definitely not happy about it, but for some reason they decided it didn't make sense anymore to give user's of their products a great experience (clearly I'm not over this yet lol.)

Anyways, now I'm in need of a new method for downloading icons while I sketch wireframes, and I figured what better community to ask for help on this than the dev community! Any of you guys know of a good tool that accomplishes the same thing as Adobe assets?

Ideally it would be free all though I wouldn't mind a product with a small fee attached.

Also, I'm considering dropping Adobe Creative Cloud all together, since I really only used it for Adobe XD and now that I feel like the seamless UX of the whole design process is heading south I'm looking at other options. I've tried sketch but I find it complicated compared to the simplicity of Adobe XD. Anyone know of any other good alternatives?

What's the Craziest Question You Ever Asked on Stack Overflow?

Josh Hadik — Thu, 14 Feb 2019 07:08:43 +0000

As developers who have progressed out of the "beginner" phase, we often underestimate just how far we've come. That's the nature of programming. Things that at one point seemed like the most complex thing in the world become second nature, so we write them off.

Slowly, over time, we become better and better developers. And as we grow, we often forget the pain we went through, which at best leads us to overlook our own talent and value, and at worst makes us hostile towards new developers ("You don't even know what X does? How can you call yourself a programmer!")

I thought it would be a fun exercise for those of us who have "been around" for a while to look back at some our oldest questions on Stack Overflow, the stuff from way back when, and share some of the "craziest" stuff we ever asked. The stuff that seems so basic and fundamental to us now, but at one point made about as much sense to us as quantum physics (or some other crazy complex concept if you happen to be an expert in the field.)

If you're a beginner reading this, I hope this discussion helps you realize that we've all been there, and if we can do it, so can you!

And if you're past the beginner phase, I hope this exercise helps you realize the value of your own skill, and makes you a little bit more understanding of and forgiving towards newer developers.

So here it goes.

What's the craziest question you ever asked on Stack Overflow?

Feel free to add explanations, code snippets, links to the questions, and any other information you want!

If you are a new developer and any of these examples are something you currently struggle with, I hope labeling them as "crazy" isn't off-putting. The intention here isn't to make anyone feel stupid for not knowing something, but rather to highlight that we've all struggled with the same fundamental concepts at some point in our developer career.

The Many Worlds of Programming

Josh Hadik — Tue, 12 Feb 2019 01:10:45 +0000

I remember when I first started learning Elixir. It was a little over a year and a half ago.

At the time, I was living happily in the world of Object Oriented Programming with Ruby, a world where everything made sense to me. I knew how to use objects and methods and classes and inheritance and everything just felt right!

Then it happened. One fateful night, after a growing desire to dip my toes in the waters of Elixir, I decided to venture far off into unknown territory, into the world of Functional Programming. It was scary and unfamiliar at first, but also exhilarating. A world built on functions and processes and supervisors and concurrency. Everything was new and everything was exciting.

Before my adventure, I was in that state of blissful ignorance so many post-beginners find themselves in at one time or another. I thought I knew it all. I had mastered the world of OOP and, for a brief moment, I was both naive enough and lucky enough to believe that I had made it. I had mastered programming.

Oh how wrong I was.

That journey on that night changed me. It opened up my eyes. How could I have been so naive as to believe I had mastered everything in just two short years? How many other unknown worlds were out there? Just how vast was the cosmos of programming really?

And so now, almost two years later, I’ve decided to set out on a new adventure. Not to master every world, not even to visit every world, there’s not enough days in a lifetime for that.

No.

I simply wish to map out the many worlds of programming.

The Many Worlds of Programming

The idea behind this post is that development is kind of split into many different "worlds" like you might see in a video game. And that we as developers can travel from world to world learning new skills (or stick to one world and master it)

I want to touch on of some of the different worlds of programming I’ve been introduced to (or at least heard of), as well as some of the key pieces that make up that world.

I’m not an expert in every single one of these fields, and I might put certain things in places you don’t agree with. Please let me know in the comments if you disagree with anything in the list. Also this isn’t complete, I’m sure I’ve missed at least half of the key worlds of programming out there. I’d love to make this a ‘community’ effort to map out all the worlds.

Basic Programming

This is the most basic level of programming, the place where almost every coder, no matter what field they're interested in, starts. It is made up by the key components of programming logic.

Key Components

Data Types
Variables
Collections
Basic Operations
Conditional Logic
Iteration

Object Oriented Programming

Probably the most popular paradigm in development. Object oriented programming is a method of programming whereby systems and applications are based on the use of different objects and how they interact with each other.

Key Components

Classes
Methods
Objects
Inheritance
Polymorphism
Abstraction
Encapsulation

Functional Programming

Functional Programming is on the rise, and it helps remove some of the key pitfalls of object oriented programming, such as the unpredictable nature of testing methods based on external factors (in-memory state) or thread deadlocks. Functional programming is based on the manipulation of data through the use of mathematical functions (1-to-1 input/output ratio.)

Key Components

Functions
Processes
Supervisors
Concurrency
Recursion

Low Level Programming

Low Level Programming is something I am not totally familiar with, as I've dealt with mainly higher level languages. The idea with Low Level programming is that you deal with data in a similar manner to how the processor deals with it, without all of the abstraction of new-age languages. The lower you get, the less complexity is taken care of for you, so you have to worry about things like memory allocation, pointers, garbage collection, and even bit manipulation on your own.

Key Components

Memory Allocation
Pointers
Bitwise Operations
Assembly
Machine Code
Binary

Theoretical Computer Science

I could have just as easily called this world 'preparing for the interview.' This world is comprised of a lot of the stuff you would learn during college, and deals a lot more with the theory and mathematics behind programming than actually putting code into practice.

I learned to program at a bootcamp, so I'm lacking a bit of expertise in this area and I'm sure I missed quite a bit of the core components. Let me know if you think anything should be added!

Key Components

Data Structures (Sets / Stacks / Queues / Linked Lists / Trees / etc.)
Algorithms (Binary Search / Bubble Sort / etc.)
Big O Notation
Space vs Time Complexity

Testing

Testing is one of the most important things you can do to ensure the quality of your code remains consistent. Testing code is a way to simulate the use of certain functions or features in your code with specific input or interactions, and ensure that the code does what you expect it to do.

Key Components

Unit Tests
Integration Tests
Mocks & Stubs
Factories
Benchmarks

Data Management

Data Management is the field that deals with how you store for your applications or services, instead of how you compute that data. In this world, you will find many different unique ways to store data-each best suited to specific situations, tricks you can use to speed up access to that data, and patterns you can use to ensure data integrity and avoid data loss.

Key Components

SQL
Relational Databases
Indexes
NoSQL Databases
Graph Databases
In-Memory Datastores (Redis)
Data Integrity

Data Transfer

Data Transfer deals with how you transfer data from device to device across the internet or other networks. A lot of developer stick to the high-level protocols and patterns that use abstraction to hide a lot of the internals of what's going on, but when you dive deep into this world there's a lot you can learn!

Key Components

OSI Model Layers
TCP / IP
HTTP
Sessions / Cookies
SSL / HTTPS
REST
GraphQL

DevOps

DevOps is somewhat of a buzzword these days, and there's a reason for that! One of the biggest bottle-necks in the web development process is getting the code that runs on a developers local computer up and running on a server and accessible to the world! Due to differences in environment, developers often face many problems and errors when finally deploying their code. DevOps is a branch of programming dedicated to best practices and tools you can use to ensure that the transition from local code to live code is as seamless as possible.

Key Components

12-Factor App
Git
CI/CD
Automation Tools
Docker
Kubernetes

Operations

Operations is all about how your code runs in the wild. On your local machine, you can often download programs that make it easy to store data, or run your code. In production however, you have to rely on custom servers or a variety of cloud services to make sure your app is accessible by users and runs consistently.

Key Components

Hosting & Domains
AWS / Google Cloud / Digital Ocean / Heroku
Linux
SSH
Firewalls & Security
Logs

Frontend (Fundamentals)

Frontend is a word typically used to describe the client-side environment of your application on the web. Put another way, the frontend is what the user actually sees. In the old days, this typically meant HTML files with some CSS, and a little bit of JavaScript to handle some animations and calls to the backend. A lot has changed since then, but this world is still as applicable as ever, and will teach you a lot of the fundamentals that will help you grow as a developer.

Key Components

HTML
CSS
Javascript
JQuery/AJAX

Frontend (New Age)

Recently, frontend development has experienced a pretty radical shift from the old days of HTML, CSS, and JavaScript. This has happened as a lot of tools, standards, and frameworks have been developed or implemented that speed up development by taking care of a lot of the common features or problems that you used to have to code by hand.

Key Components

React vs Vue vs Angular
Webpack
Bootstrap / Materialize
EMCAScript 6+
Progressive Web Apps
SPA vs SSR
Redux

iOS Development

This one is pretty self-explanatory. If you want to develop any apps for Apple's mobile operating system iOS, you will need to learn how to navigate the key components of this world.

Key Components

Swift / Objective C
XCode
Storyboards
Segues & ViewControllers
UIKit
CocoaTouch

Architecture

Thanks @laurie for the idea for this world!

Architecture is the field of computer science that deals with how software systems are designed and interact with each other. Architects must have a broad knowledge of the different requirements of an application or service and be able to identify the right design patterns and organization techniques to use to ensure the service runs smoothly, meets requirements, and remains maintainable, expandable, and scalable!

Key Components

Code Patterns (MVC / Abstraction / etc.)
Architectural Patterns (Microservices / Containerization / Client Server Split / etc.)
Interdependencies & Coupling
Coordination
Security

Missing Worlds

Below is a list of worlds I know are missing from the list, if you have experience with any of them, please leave a comment with a quick description of the world and a few key components (doesn't need to be a complete list, just something to get started!)

Let me know what else you think is missing!

Android Development
Security
Hacking
Machine Learning / AI
Game Development

I Need Your Help

This is an incomplete list.

Please feel free share any worlds you think are missing, as well as any of the core components of a specific world you think should be added, I will try my best to update the list accordingly.

I'm messing around with the idea of eventually building some sort of cool graphical website for the 'Many Worlds of Programming' with a brief introduction to each, the key pieces (as listed above), and links to some of the best resources out there for each individual world. Let me know if you'd be interested in using or contributing to a website like that!

Don't Do It “Because Google Does It”

Josh Hadik — Fri, 08 Feb 2019 23:53:42 +0000

This is a comment I wrote a little while back, you can see the full context here, but the premise of the conversation was about how companies like Google and Facebook have a totally different set of requirements when hiring programmers than startups or smaller companies.

[...] Companies like FB, Google, and Amazon need to test programmers on data structures because certain structures work better in certain situations, and when their software engineers know which tools to use to optimize a process to run in 5μs instead of 10μs... well, let’s just say for a company running tens or hundreds of thousands of servers, every microsecond saved means less servers the company needs running. And less servers = more $$$.

But for most startups or mid sized companies it’s way more important that developers know how to get shit up and running, and less important the actual code they write to get there.

The problem is a lot of smaller tech companies look up to companies like Google and try to copy they’re interview process because hey, it’s Google. And these companies never consider that just maybe an app with billions of users has a slightly different set of requirements than their app with 500 users.

Read that last sentence again:

And these companies never consider that just maybe an app with billions of users has a slightly different set of requirements than their app with 500 users.

I think this is super important in todays landscape. A lot of MVP teams, startups or mid-sized companies try to copy companies like Google or Facebook, which makes sense on the surface...

I want my app to be the ${topTenApp} of ${industry}, so why wouldn't I use the same tools and processes as them?

Here's the difference.

Google used that tool or process to solve a very specific technical problem they faced as they grew, versus the copycat company that didn't actually solve anything by using the tool, but actually created more problems.

Kubernetes is a powerful tool for scaling services, but you won't ever need to use it if you don't actually have any users to scale for.

Using it to develop an MVP just adds unneccessary complexity, slows down development time, and makes hiring suitable developers harder down the road. Just stick with the Heroku hobby dyno and change it when you actually need to.

This same rule applies to dozens of tools and patterns. Microservices. Machine learning. React native. CDNs. Jenkins. GraphQL. Blockchain. ElasticSearch. The list goes on and on.

I'm not saying you shouldn't use any of these in your initial build. If the whole premise of your app is to build a smart contract based ledger for real estate then of course you'll need to use blockchain, but if you're building a social media site for equestrians you probably don't need to use machine learning for suggesting content in the beginning.

When you're starting out, you should use a tool for one of two reasons:

1) It's absolutely essential for your MVP.
2) It increases productivity.

That's it.

Everything else can be changed, fixed or added later on.

Don't be a perfectionist and don't solve problems you don't have.

Just make something good enough that users actually want to use it, and worry about scaling when you need to.

If you do this the other way around, you might just waste months building a perfectly useless app.

You’re Allowed to Break Your Own Advice, and You’re Allowed to Change Your Mind.

Josh Hadik — Fri, 08 Feb 2019 07:50:22 +0000

In a community like this one (or any community), there’s a common fear people have that if they say something, the have to live it.

That if they go out of their way to give some sort of technical advice, they need to make sure they stick to that 100% in all their code across all their public repos.

That if they don’t, they’ll be labeled a hypocrite.

This is a lie.

You don’t need to follow your own advice 100% of the time, and you shouldn’t be afraid to share your opinion if you don’t.

I used to smoke, (and I might still indulge in the occasional cigarette.)

That doesn’t mean if someone asks me point blank if they should pick up smoking, I have to say yes. My answer would be no, of course they shouldn’t! It’s a bad habit that wastes your time, drains your bank account, makes you smell like garbage, and ruins your health.

I can say that even though I still smoke sometimes.

Same thing goes for giving technical advice. It’s ok to speak your mind even if you don’t always do what you say.

No one does.

This is programming for gods sake, most people don’t follow their own advice 90% of the time.

Never feel like you can’t share your opinion if you don’t always stick to it, and never feel obligated to always follow your advice just because you shared it!

Oh and another thing...

It’s ok to be wrong.

And it’s ok to change your mind.

Loads of people who used to preach DRY now preach WET.

And tons of people who used to be zealots about 100% test coverage now say its a waste of valuable time trying to test all those once-in-a-lifetime edge cases.

People learn. People change. People grow.

I hate to think that there’s some of you out there with unique, valuable thoughts, afraid to share them just because they don’t always stick to them, or because they’re not absolute experts on the subject.

If that sounds like you, I’m here to tell you that it’s ok! Communities like this thrive on different people with different levels of experience coming together and sharing their experiences and opinions.

So share your thoughts, no ones gonna judge you if you change your mind!

Ten Tips to Get the Most out of Your Rapid Reps

Josh Hadik — Wed, 06 Feb 2019 00:45:27 +0000

This is part two in a series about a strategy I use to learn new skills every week, something I call Rapid Reps. You should read the first article if you haven't already, it lays out exactly what Rapid Reps are and why they're effective.

In this article, I lay out my top ten tips for how to get the most out of your daily Rapid Reps!

Pick a time, place, and duration.

The beauty of Rapid Reps is you can set them up to work with your schedule. If you’re currently unemployed trying to learn new skills to impress potential employers, you can choose longer tasks that take an hour or more. If you work from 8 to 6 and just want a small way to keep you on your game, you can choose small tasks that you can finish in 30 minutes or less when you get home from work.

Me personally? I like to keep mine to 45 minutes or less and do them with my morning cup of coffee.

Don’t overextend yourself.

Be realistic. If you only have 30 minutes every day to complete a rapid rep, don’t pick a task with eight different new technologies you’ve never worked with before (eg: build a React/Redux app with a Express GraphQL API and deploy it to Google's Kubernetes Engine with Travis CI). Find one technology you want to learn, hone in on that every day for a week, and move on to the next one the following week.

Don't be afraid to change midweek.

Sometimes we as developers overestimate our capabilities, or underestimate the difficulty of a task. I've found myself on more than a few occasions breaking the last tip and overextending myself. A task that I thought would take 45 minutes ends up taking over two hours.

In cases like these, never be afraid to change course in the middle of the week. Try breaking the large task up in to two or three smaller tasks that you can complete in the following weeks. Rapid Reps aren't meant to take all day, and you should do everything you can to contain them to a set amount of time.

Take a day off.

Personally, I try my best to take full day off from any form of coding each week. It gives me a chance to clear my head a little and refresh my mind, which in turn helps me to get back into the coding grind the next day with more focus and energy. This means you should ideally aim to do six reps per week, with a designated day off.

Do as much from memory as possible.

Each day you should strive to do as much from memory as possible instead of copying and pasting code you wrote during your previous rep. Even though the goal of this isn’t to memorize the line-by-line syntax needed to solve a specific problem, it never hurts to force yourself to practice it a little!

Do the task once before your first rep.

Rapid Reps help you repeat a process enough times that the core concepts and workflow gets embedded in your memory, but you might want to consider walking through the process once beforehand so you know what you're doing!

Whenever I try to tackle a new task, I like to take an hour or so on the Saturday beforehand to walk through a tutorial and really figure out the process. That way on Monday, when I do my first rep, I already have some idea of what I need to do and don't spend an extra two hours just trying to learn.

Make small additions throughout the week.

At first, just completing the task will be hard enough, but usually by about day 3 or 4 you’ll be zipping through the rep in half the time it took on day one. At this point, I like to look for one small additional task I can add to the process each day!

Here’s some examples of how I've put this into practice:

Example 1 -> When I did a week of reps focused on learning how to implement OAuth in a Phoenix application, I started by just setting up OAuth with one provider, Github. Around day three I added Facebook, then Google, and by the last day I had an app you could log into with Github, Facebook, Google, or Twitter, and I even built a pretty cool system for easily adding new OAuth links in a DRY manner

Example 2 -> When I did a week focused on setting up Multi-container deployments to Elastic Beanstalk with Travis CI, I started with a super basic workflow that deployed to a single environment, and by the end of the week I had fully autonomous system for building docker images and deploying to two separate environments based on git branch, one for production and one for staging.

Use continuity across weekly tasks.

This one is kind of similar to the last one, but instead of focusing on additions made to one task over the course of a week, this is about creating a continuous flow between the nature of the task you complete from one week to the next.

So if you have a certain skillset you’re really interested in learning, break it down into one really simple ‘starter’ task, complete that task every day for one week, and then build on that with each new week of Rapid Reps.

As an example, one of the skills I was interested in learning a couple months ago was how to setup a CI/CD workflow that allowed me to easily deploy multi-container apps. Rather than trying to do it all at once, I decided to start small by focusing one week on building a single Docker image that ran locally and building from there. Here’s the basic flow I followed:

Week 1 -> Build a single working docker container from a docker image.
Week 2 -> Build a dual container environment and use docker-compose to connect the two together on my local environment.
Week 3 -> Build a single container application and push it to Elastic Beanstalk with Travis CI.
Week 4 -> Build a dual container application and push it to Elastic Beanstalk with Travis CI.
Week 5 -> Build a multi container application, push it to Elastic Beanstalk with Travis CI, and setup RDS as the database layer.

Keep in mind that at the start I barely knew what Docker was, had never used a CI tool in my life, and hadn’t used AWS for anything more than simple S3 bucket storage. I’d say I’ve come a long way since then.

Make cleanup a part of your reps.

This is especially important if you’re using pay-by-the-second cloud services like AWS and want to pay as little as possible (ideally nothing if you're on the free trial.)

I like to start each rep by making a checklist of all the steps I need to do to finish whatever task I’m working on, and the last item on the checklist is always clean up! This means going through every online service and cleaning up whatever I made during the rep, whether that’s deleting a Github Repo, shutting down an Elastic beanstalk environment, or removing images on Docker hub, I like to clear out everything except for the code on my computer.

The last thing you want is a hundred useless images and repositories cluttering your online work environment, and, if you’re not careful, they'll add up pretty quickly when you start doing Rapid Reps every day.

Refactor and showcase your code on the last day.

When I finish my last rep of the week, I try to spend an extra thirty minutes or so afterwards going through the code and cleaning it up. I also remove any "vulnerable" information that might have slipped in (environment variables, api keys, etc.)

Once I'm done, I copy the code over to a separate git repository and push it up to GitHub. This serves two main purposes:

It ensures you never lose the 'example code' you wrote during that week Rapid Reps, in case you ever want to look back at it for reference.
It gives you a nice repository of code that you can use in the future to showcase your skills to a potential employer!

Bonus tip - use the streaks app!

I am in no way affiliated with the Streaks app, I just think it's a useful tool that works well with Rapid Reps

Streaks is an iPhone app that lets you set a number of habits you'd like to implement into your daily routine. Everyday when you complete that task, you can open up the Streaks app and mark it complete, and Streaks will show you the number of days in a row you've finished that task, otherwise known as your 'streak.'

I have one of my tasks set to Rapid Reps, and as of Feb 5, 2019, I'm on day 80! I find that using the streaks app gives me a little bit of motivation everyday to complete my rep, since I don't want to break the streak!

Streaks is only available on the iPhone, let me know in the comments if there's a good alternative for Android.

Thanks for reading

I hope you enjoyed this article! Feel free to ask any questions or leave your feedback in the comments below!

Which Do You Value More, Your Time or Your Privacy?

Josh Hadik — Tue, 05 Feb 2019 20:00:00 +0000

Privacy advocates and anti-big-tech individuals seem to be very outspoken about the dangers of technology and centralized information, but you never hear much from the other side. The way I see it there are two groups of people. 1) Those who value privacy over time and 2) Those who value time over privacy. Let’s take a closer look at the two.

Team Privacy

As a member of team privacy, you value your privacy.

You would rather spend a little extra time doing something yourself than giving up your personal information to let technology do it for you.

You tend to distrust big business and prefer to use products and apps built by smaller companies you trust.

Team Time

As a member of team time, you value your time.

You don’t mind giving up a chunk of your personal info in exchange for the convenience technology brings and the time it can save you.

You tend to use products and apps built by bigger tech companies because they're easier to get started with and they seamlessly integrate your information across your devices and accounts.

Which are you?

Are you on #teamprivacy or #teamtime? https://t.co/H6wKyVzK7L
— Josh Hadik (@joshhadik ) February 5, 2019

Feel free to defend your side if you want, just keep it friendly!

Are you on #teamprivacy or #teamtime?

How Do You Continuously Learn?

Josh Hadik — Tue, 05 Feb 2019 08:19:17 +0000

In a world where users constantly change how they interact with technology, where break-through technologies are only ever a few months a way, and where new JavaScript frameworks pop up almost daily, one of the best things we can do as developers is to constantly learn.

Whether that means learning a brand new language, how to follow a different coding pattern, how to use the latest DevOps tools, or something else entirely, it's important that we find ways to build continuous learning into our lives.

I've already written about something I do everyday to keep me learning, but I'm curious to hear from the dev community...

What habits or techniques do you use to continuously learn new skills?

Organize Your Side Projects with a Single Domain!

Josh Hadik — Tue, 05 Feb 2019 05:07:13 +0000

If you’ve built a few side projects over the years, chances are you’ve ended up using a few domains like this: something-super-cool.herokuapp.com. And if you’re at all like me, you hate using those domains, because it just feels kind of impersonal to use a subdomain of a hosting site like Heroku or Elastic Beanstalk for your project.

So naturally, you look up pricing to see how much it would cost to buy your own domain. It’s only $15 a year! That’s not too bad. The thing is this project isn’t that important, and you have 15 other equally unimportant projects using a herokuapp subdomain.

So you do a little math.

15 projects times $15/domain = $225.

That's too much.

You stick with the herokuapp subdomain.

But what if there was a better way?

What if you just bought one side project domain, and used subdomains of it for all of your personal projects? Kind of like an online ‘repository’ site for all your personal projects. Something that let you organize projects like this:

project-one.mysideprojectsdomain.com
project-two.mysideprojectsdomain.com

Well, this might sound great, but if you’re the type of person who spends a majority of your time on the development side of things and rarely touches the operations side, your experience with setting up domains probably looks a little something like this:

Google how to setup a domain.
Read an article on how to setup a domain.
Copy exactly what that article says.
Visit new domain and see this:
Spam refresh for 20 minutes.
Repeat steps 1 - 4 with a slightly different article.
Spam refresh for 20 minutes.
Repeat steps 1 - 4 again with a new slightly different article.
Spam refresh for 15 minutes.
It worked!

Once you see your site finally up and running, it’s usually followed by an overwhelming sense of relief. And that sense of relief is followed almost immediately by a decision that you will never, for as long as you breathe, touch the settings for that domain again.

I know because up until three months ago, this was my exact experience with setting up domains.

But recently I’ve been getting into the operations side of things, and guess what? Setting up a domain is actually easy. Like really easy.

At the end of this article I’ll give a quick step by step guide for setting up a Heroku app with a Route 53 subdomain, but first, I want to take a look at a more practical reason why you should consider setting up a side project domain.

A practical reason to setup up a side project domain.

It’s not just about having a pretty URL.

Using a hosting services subdomain also couples your app too tightly with that service.

Suppose the unthinkable happens, and one of your side projects actually takes off... you wake up one day and all of the sudden your app has hundreds or thousands of visitors. And not just that, but people are tweeting about it, and blog posts are being written about it.

Now you start thinking that maybe your app has a real shot at being something big, and you know the hobby dyno on Heroku won’t be enough to handle traffic for long, so you decide to move your site to Google Cloud.

But wait… all of those tweets and blogposts… they were all linked to your Heroku subdomain… and you don't want to lose all that traffic…

If only you had used a side project domain!

Truthfully there are other ways around this problem. You could setup a simple app on the Heroku site to redirect traffic elsewhere, but even then you’d have to pay $7 a month just to keep that app up 24 hours a day.

It’s just easier to use a side project domain, and with the low prices of domains these days it should be a no brainer.

Plus, if you decide one day that your app has grown enough and you want to get a unique domain for it that isn’t attached to your side project domain, it’s extremely easy to redirect traffic from one domain to another.

Alright, now that you're convinced, here's Seven Steps to Set Up a Side Project Domain with Route53 and Heroku.

Thanks for reading

I hope you enjoyed this article! Feel free to ask any questions or leave your feedback in the comments below!

Seven Steps to Setup a Side Project Domain

Josh Hadik — Tue, 05 Feb 2019 05:06:46 +0000

I wrote a separate article called Organize Your Side Projects with a Single Domain that explains what a side project domain is, and why you should use one.

I highly recommend you read that article first, as this post was originally meant to be just a quick walkthrough at the end of that article, but I decided to separate it into it's own post to keep things short and to the point.

How to Setup a Side Project Domain with Route53 and Heroku.

I chose to use Route53 and Heroku in this article because I think they are two of the most popular and easy to use solutions out there, however, even if you use two totally different services, it should be easy enough to follow along and figure out what the minor differences are.

Step #1
Choose a side project domain

Try to keep it short.

I like the idea of using a ‘username’ style for your side project domain, something you might use on Github or Stack (maybe even something you did use on Github or Stack.)

I went with jhadik307.com

Step #2
Purchase the domain on Route 53

You don’t have to use Route 53. I chose it because it’s really easy to use, and because I use AWS a lot so it’s nice to have everything consolidated in one place. If you choose to use something else, the steps will be a little different, but it should still be easy enough to figure out.

Assuming you're using Route 53, and you already you have an AWS account setup, visit the Route 53 home page. Once there, type your new domain name under the Register domain section and check if it’s available!

Once you find an available domain, click 'Add to Cart' and follow along with the checkout process to purchase your brand new side project domain!

Step #3
Come up with a subdomain for your project.

One of the best parts about using a side project domain is that none of the subdomains will be taken! This means you can use whatever subdomain you want, most likely just the name of your project.

I'll be using 'somethingsupercoolijustmade' for mine, but you can feel free to use the name of one of your existing side projects, or to use whatever else you want to as a subdomain!

Step #4
Add the full domain to your Heroku app

Visit your existing Heroku project or start a new one, then go to the settings tab for your project and find the section ‘Domains and Certificates.’ Once there press 'add domain' and type in the full domain name for your side project (with the subdomain included.)

Step #5
Copy the DNS Target.

Copy the text found in the DNS Target for your new domain on Heroku (as seen highlighted below.)

Step #6
Setup subdomain on Route 53

Go to the hosted zones section for your new domain on Route 53 and click ‘Create Record Set.’
Enter the subdomain in the ’name’ field, choose CNAME as the type, and paste the DNS target in as the value.

Note - never copy the protocol (http / https) at the beginning of the domain into the cname value box

Once your done, click create.

Step #7
Visit your new site!

Thanks for reading

I hope you enjoyed this article! Feel free to ask any questions or leave your feedback in the comments below!

Ruby vs Elixir - FizzBuzz

Josh Hadik — Fri, 01 Feb 2019 03:10:59 +0000

I've been working through a lot of common interview questions recently as part of my daily reps, something I do everyday to force me to learn constantly and hone my craft. I decided rather than solve each problem in just my native language of Ruby, I'd solve each problem twice, once in Ruby and once in Elixir. You can read a little bit more about why I chose to do that here.

I figured while I'm doing that, it might be interesting to write about some of the key differences I notice between the two. So that's what this is, a quick breakdown of some key differences, not a step-by-step guide of how I came to the solutions.

In these examples, I tried my best to use each language in the truest form possible, meaning in Ruby I followed a strict object oriented approach and relied primarily on objects, mutation, instance variables, and iteration, and in Elixir I followed a strict functional approach and relied mainly on functions, piping, pattern matching, and recursion.

I also tried my best to make the two solutions read as similarly as possible by using similar function names, variable names, and general order of operations.

Ruby FizzBuzz

# ruby
class FizzBuzz
  def initialize(max)
    @max = max
    @fizz_buzz_array = []
  end

  def play
    populate_fizz_buzz_array
    display_fizz_buzz
  end

  private

  def populate_fizz_buzz_array
    1.upto(@max).each do |num|
      value = get_fizz_buzz_value(num)
      add_value_to_fizz_buzz_array(value)
    end
  end

  def get_fizz_buzz_value(num)
    if num % 15 == 0
      "FizzBuzz"
    elsif num % 3 == 0
      "Fizz"
    elsif num % 5 == 0
      "Buzz"
    else
      num.to_s
    end
  end

  def add_value_to_fizz_buzz_array(value)
    @fizz_buzz_array << value
  end

  def display_fizz_buzz
    puts @fizz_buzz_array
  end
end

## USAGE

fizzbuzz = FizzBuzz.new(15)
fizzbuzz.play

# 1
# 2
# Fizz
# ...

Elixir FizzBuzz

# elixir
defmodule FizzBuzz do
  def play(max) do
    max
    |> create_fizz_buzz_list()
    |> display_fizz_buzz()
  end

  defp create_fizz_buzz_list(list, 0), do: list
  defp create_fizz_buzz_list(list \\ [], num) do
    num
    |> get_fizz_buzz_value()
    |> add_value_to_list(list)
    |> create_fizz_buzz_list(num - 1)
  end

  defp get_fizz_buzz_value(num) do
    cond do
      rem(num, 15) == 0 -> "FizzBuzz"
      rem(num, 3) == 0 -> "Fizz"
      rem(num, 5) == 0 -> "Buzz"
      true -> to_string(num)
    end
  end

  defp add_value_to_list(value, list) do
    [value | list]
  end

  defp display_fizz_buzz([]), do: :ok
  defp display_fizz_buzz([head | tail]) do
    IO.puts(head)
    display_fizz_buzz(tail)
  end
end

## USAGE

FizzBuzz.play(15)

# 1
# 2
# Fizz
# ...

Things I noticed

1. Elixir encourages declarative programming

Take look at 'create_fizz_buzz_list' and 'populate_fizz_buzz_array'

# ruby
def populate_fizz_buzz_array
  1.upto(@max).each do |num|
    value = get_fizz_buzz_value(num)
    add_value_to_fizz_buzz_array(value)
  end
end

# elixir
defp create_fizz_buzz_list(list \\ [], num) do
  num
  |> get_fizz_buzz_value()
  |> add_value_to_list(list)
  |> create_fizz_buzz_list(num - 1)
end

In the Ruby version, unless your an expert at the language, you almost need to take a minute to examine the code just to make sense of what's going on, whereas the Elixir counterpart almost reads like a book (all though the final line might be a bit confusing.)

Of course, I could have written Ruby to be a bit more declarative, but the point of this was to follow common patterns and write code the way I actually would in the real world, and I think Elixir does a better job at encouraging the use of a more declarative style of coding.

2. Elixir encourages better abstraction

Look at the function/method where I add the fizz buzz value to the collection:

# ruby
def add_value_to_fizz_buzz_array(value)
  @fizz_buzz_array << value
end

# elixir
defp add_value_to_list(value, list) do
  [value | list]
end

Notice how in Ruby, I called it "add_value_to_fizz_buzz_array," but in Elixir, I dropped the "fizz_buzz" and just called it "add_value_to_list." This was very intentional. In Ruby, the method call is adding the value only to the predefined fizz_buzz_array, however, the Elixir function is a bit more generic and adds the element to whatever list the function is called with.

This means that the Elixir function is quite a bit more flexible than the Ruby version, and could easily be abstracted into some other module and reused throughout the code.

Again, I know I could have written Ruby with a more functional approach and achieved the same behavior, but the fact is, in Ruby, the standard way to make changes is to do exactly what I did and manipulate instance state internally through the use of methods.

3. Elixir works better "backwards"

Because lists in Elixir are actually linked lists and not indexed arrays like their counterpart in Ruby, I had to take a different approach when interacting with them.

In Ruby it's cheap and easy to append to the end of an array so that's become the defacto way to add elements to an array, which is exactly how I did it in this example.

On the other hand, in Elixir it's easier and requires much less processing power to add elements to the beginning of a list, due mainly to the way linked lists work.

That alone isn't very noteworthy, but what I found interesting about it was it changed the entire direction I worked through the numbers in. In Ruby, because I was adding to the end of the array, it made the most sense to start at 1 and iterate up to 15:

# ruby
1.upto(@max).each do |num|
  # ...
end

However, in Elixir, because I was adding to the beginning of the list, it made more sense to start at 15 and recursively work my way down to 1.

# elixir
create_fizz_buzz_list(num - 1)

4. Ruby is more likely to cause unexpected side effects

In a functional language like Elixir, if something works once, it works twice. There's almost always a one-to-one relationship between input and output. With object oriented languages on the other hand, you have to be a little bit more careful.

Notice how I'm never clearing the @fizz_buzz_array variable in Ruby, just adding new elements to it. If I try to 'play' a specific instance of FizzBuzz one time, it works like a charm. But what happens if I try to play the same instance twice?

# ruby
fizzbuzz = FizzBuzz.new(3)
fizzbuzz.play

# 1
# 2
# Fizz

fizzbuzz.play

# 1
# 2
# Fizz
# 1
# 2
# Fizz

This is a glitch you probably wouldn't think to test, and something you might not even realize is happening unless you have a deep understanding of Ruby and the Object Oriented programming pattern. This glitch is easily solvable. I could clear the array in every time I populate it, or I could move the entire "populate_fizz_buzz_array" method call from the play function to the initialize function so the array only gets populated once, but I decided to leave it in as an example of how in OOP it's often times very easy to have less-than-ideal side effects slip under the radar.

I don't hate Ruby

When I came up with the “things I noticed” list, it was after I had already written all of the code. I tried to write honest stream of consciousness of what I noticed while I looked back over the code. I know a lot of these points seem like I'm really hyping up Elixir and shitting on Ruby, but that wasn't my intention going in, that was just the honest list of the things that stood out to me when I compared the code.

If it seems like I have a strong bias towards Elixir, I think that's because Elixir is the new, exciting language that I've only recently started working with, whereas Ruby is the old, almost boring language that I've worked with for years. Elixir to is the 'greener grass on the other side,' so right now I know I'm prone to seeing only the good and not the bad. I'm sure once I become a more familiar with Elixir I'll have a more balanced view of the good and the bad of both, but for now, I definitely find myself drawn to the way things are done in Elixir.

What do you think?

Does anything else stand out to you about the difference between the two solutions? Which version do you prefer?

Thanks for Reading!

If you found this article interesting or informative and want to see more articles like it, let me know! And feel free to let me know what you think would be a good topic for my next Ruby vs Elixir article! (Fibonacci? Factorials? Something Else?)