DEV Community: Binyamin Galinsky

What will you want to read?

Binyamin Galinsky — Fri, 20 Jul 2018 05:28:29 +0000

I wrote some blog posts recently and I'm in the retrospective stage analyzing the data from those posts.
It seems that people prefer career stuff over technical stuff.
What do you like to read?

5 Lessons learned from side projects

Binyamin Galinsky — Fri, 29 Jun 2018 15:12:30 +0000

// Detect dark theme var iframe = document.getElementById('tweet-1004342391137034240-631'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1004342391137034240&theme=dark" }

From my first days as a professional software engineer, I always spent some time in developing my own side projects. While some side projects doesn’t make sense (like the tweet above), I saw that side projects were a huge benefit for my career, so I decided to write some of the lessons I learned of how to maximize the effect of side projects.

Go live!

Yes, you heard me… Go live with your side project! Recently I built my challenge web site, (www.mypopchallenge.xyz) and while the UI is not very impressive, I found very interesting challenges when it came to deployment. The fact that my 1 year with free tier at AWS is over made me write some scripts to synchornize between my now.sh instance and Netlify deployment so I can use them both and keep my expenses to the minimum.

Going live is not just about publishing your app to the app store or deploying your website to the web. It can be publishing a library to npm or even just open sourcing the code so people can see it, use it and learn from it.

So here is my first suggestion — Go Live!

Don’t try to make money out of it

When you’re trying to make money out of your app, you start to get crazy. You can imagine yourself in piles of money and you are working towards it. Isn’t that good? I think it is amazing. It is a spirit of entrepreneurship and lots of good products started like that. But this is not a side project. You definitely will learn a lot but when you start to see money out of it, it will be very hard to abandon it, which is sometimes the right thing — to concentrate more on your daily job or to start a new side project with a new technology you want to learn.

And here is my advice — build side projects for fun, not for money.

Learn incrementally

So you have an idea: it’s the best ToDo app the world has never seen… You heard about this amazing front end framework that has 1 billion stars on GitHub and the server must be with that data transfer hot framework, you also know 3 cool JS libraries that you must try, and you want to try your skills as microservices architect. Sounds a lot? It is a lot! side projects has the nature of being fuelled solely by motivation only, and as such you need to see results fast, or the motivation will blow away for the next cool idea. And guess what, in a month you will have another half baked repo with 2 microservices, half of data layer and a piece of front end.

My advice — choose one new technology at a time for your side projects.

Work alone

90% of a problems in a software development team are communication problems, the rest are problems that people can’t communicate well enough to explain. When you add a members to your side project team, you need to spend time on communication. And while communication with other people is awesome, you won’t get the benefit that you want your side project to give. (I’m not coding on in code communication methods. All of my side projects documented and have full Readme files)
If you don’t want to explain why you decided to change the technology stack, or to spend 25% of your time on syncronization inside the team, leave it alone.

My advice — Side projects are exactly the time to enjoy pure experience of coding alone which is the experience most of us used to love when they choose to learn how to code.

Note: sometimes when the scope of the project is too big, you already went live and you want to go faster or you just started your side project so you can learn how to communicate better, it’s actually make sense to work together.

Code together

The fact that you’re working alone, doesn’t necessarily means that no one should see your code. When ever someone ask for my advice to improve I’m telling him this advice — “Find some one to review your code”. When I write a critical section code, I will always show it to someone. I ask a lot about the design and I am trying to get as much people involved in a friendly, advising position. If you don’t have anyone to do that for you, there are a lot of people out there that will be glad to help with that. (fun fact — I never got bad comments on my code when friends review it. I guess there is a correlation between the willingness to review someone code as a favor, and having good programming skills)

My advice — share your code as much as you can to get feedback and become better.

Conclusion

Side projects are fun. I love the feeling of showing some of my work to people and the excitement to see people interacting with my products. I learned a lot from my side projects and the lessons I gave above are highly optimized to learn. If you have other experience or another lesson that you learned from your side project, please write a comment about it. Also if you want to share your side project I would love to see a link in the comments.

This is my first cross-posting from Medium. I hope you would like it, and I hope I found a new place for positing my thoughts.

How I managed to deploy my side project for free

Binyamin Galinsky — Wed, 27 Jun 2018 11:47:28 +0000

Side projects are awesome

After my latest post about lessons learned from doing side projects I’ve been asked to help some people with their side projects. One question that I’ve been asked a lot is — “How can I just play with code and publish my side project for free”. Many of us are building stupid side projects (Like this one) and we don’t want to spend money on hosting. I believe that you should publish your work to the world, so I came up with this guide for deploying a client-server web app to for free.

It’s all about the name

https://medium.com/media/0c65a3800bace6e2a0ae1a58e28776ec/href

Think about the following situation. You come back from a party and tell your roommate about his friend that you met there. You can say “He was tall, brown eyes, had a short beard…” It can take hours… Wouldn’t it be much faster to say “I met you friend Bob in the party”? The human brain is built for names. We give name to things, then we have alias to people, places and products. That’s why you want to have a domain instead of giving people your ip address (And you must admit, seeing links to ip addresses is suspicious anyway) . You can start with free domain from http://www.dot.tk/ and later on, when your side project starts to gain some traffic and maybe even bring in some money you can upgrade to a payed domain.

Static resources need static hosting

Hosting a static website should be pretty easy. You should be able to throw your files in the cloud, point a domain to that place, and let other people try your webapp. Netlify is a place to do exactly that! Their free plan is pretty good, letting you use your custom domain, SSL and configure your Git repo for auto deployment. It’s pretty straight forward and easy to use. You should checkout their Continuous deployment.

Server deployment

While static resources are easy to deploy (and cheap to host), server is a whole different story. When no one uses your app, your statice resources are doing nothing, but your server keep running. That’s why free server solutions are rare and limited. Lucky you — There are couple free server solution that I’m aware of.

Heroku gives you a free server. You can have your custom domain, but the server will go to sleep after 30 minutes of inactivity (and it takes time to wake up a sleeping server) and you are limited to certain number of computation hours.

now.sh gives you unlimited hours but you can’t have your custom domain — the meaning is that with every deployment you will have new url that points to the new version of your server, be aware that now.sh will also open source your code.

For my side project I decided to go with now.sh, but there are some things that I did to make my experience nicer.

How to hide sensitive parts of your code

OK, so I’m not really hiding part of my code. I didn’t try to do so, and I’m not sure you’re allowed to do it by now.sh license even if you find a way. I’m talking about my passwords.

I’m ok with open sourcing my code, but I don’t want my database connection string, my product email address and its password to be open to the world. The solution is environment variables. Passing those passwords while starting the app, instead of putting them hard coded is a good practice that you should always do, but when it comes to open source, it’s even more crucial. Now supports passing environment variables through it cli tool and you need to use that ability to keep your data safe.

How to overcome the ever changing server url

As I mentioned before, now.sh does not support custom urls in its free service. Every time you will deploy a new version of your server, your server url will be changed, so you need to change the client accordingly. The first step toward doing that is having one place in the client to set the server url. I tend to have a config.js file that exposes the server url.

const serverUrl = 'https://myserver.com';
const config = {
 SERVER\_URL: process.env.NODE\_ENV === "development" ? 
 "http://localhost:3000" : serverUrl 
};

export default config;

As you can see in the code above, this is a good practice for changing environments, but it’s also very good to have one place to declare the server url, so it’s easy to change it later.

Now I wrote a script to deploy. My script has three parts. It will deploy the server to now.sh, it will take the url that now will send back, then it will change the config.js file to point to the new server url and finally it will push the changes to my deploy branch so my client will be updated. I’ve open sourced this script as an npm package and you can see it here. (The readme file contains explanations of how exactly to use and configure this script).

I hope my post will help you to deploy your side project, and I would love to hear how you use my script or what is your side project in the comments or on Twitter. If you have any questions about the script or anything, don’t hesitate to ask me. My Twitter DM box is open. As always, you can follow me to hear about my next adventure in the programming world.

Continuously running Flowtype checks with jest runner

Binyamin Galinsky — Mon, 26 Mar 2018 20:06:43 +0000

A few weeks ago I became part of a new project. The first thing I did was to set up my regular workspace in preparation for coding. My usual set up is VSCode on one screen, iTerm running Jest on the other and Chrome open in the background. Everything was perfect, I grabbed a cup of coffee, sat down in front of my desk and realised that something was missing… This project was configured with Flowtype and I wanted it to run continuously on my screen showing me if I miss some type definition (I’m a forgetful programmer and I need constant reminders while adding new tech to my stack).

My problem was that Flow don’t have watch mode.

What is Jest runner?

Jest is Facebook’s test platform. As Jest got more and more mature many abilities were implemented in it, and the core team understood that running tests is just small part of Jest abilities. One of Jest abilities is watch mode for reruns on file changes.

Since v.21 of Jest, it is possible to replace the jest test runner with your own runners and this opens a lot of opportunities like running Mocha tests using the Jest platform, running eslint linting and in our case — Flowtype checks.

(If you want to learn more about Jest as a platform, you should watch the following amazing talk)

According to Jest documentation the runner should return an object with runTests function. When Jest will run our runner it will pass it some callback functions one of those is onResult which we should call with our tests results either fail or pass.

Here is the implementation for runTests function explained in details:

We will start by storing the start time and immediately execute the flow check with child_process (note that runTests should return a promise to notify jest that the testing is done so everything is encapsulated inside a promise).

const start = +new Date();
exec('flow', { stdio: 'ignore', cwd: process.cwd() }, (err, stdout) => {

Next we will use the output that we receive as the stdout arg in exec callback to generate an object that holds all of the errors. The object is structured with the file paths as the property name and the error for that path as the value as follows:

index.js: error: String should be int

const errors = stdout.split('Error');
const errorsPerFile = errors.reduce((previous, current) => {           
  const firstErrorLine = current.split('\n')[0]; 
  const fileNameMatcher = firstErrorLine.match(/( **\.** {1,2}| **\/** )?([A-z]| **\/** |-)\ ***\.** js(x?)/);          
  if (fileNameMatcher) {            
    const fileName = path.join(process.cwd(), fileNameMatcher[0]);            
    const errorMessage = current.substring(current.indexOf('\n') + 1);            
    if (!previous[fileName]) {
      previous[fileName] = [];            
    }            
    previous[fileName].push(errorMessage);
  }          
  return previous;
}, {});

Now that we have the errors per file object we just need to iterate all of our tests and see if they have an entry in that object. If they have entry it means that we have an error in that file, otherwise we can mark this file as pass. We will use the pass and fail functions from create-jest-runner to mark our tests by their status. At the end of the method we will resolve the promise we returned.

tests.forEach((t) => {        
  let testResults;        
  if (errorsPerFile[t.path]) {        
    testResults = fail({      
      start,              
      end: +new Date(),        
      test: { path: t.path, errorMessage: errorsPerFile[t.path] },            
    });        
  } else {        
    testResults = pass(
      { start, end: +new Date(), test: { path: t.path } });          
  }          
  onResult(t, testResults);        
  });        
resolve();

That’s it. I would love to hear your thoughts about this post and what else do you think can be done with Jest-Runners. Please leave a comment or DM me on Twitter. The full code can be found in the repo.