If you are interested in Software Engineering, but you think you lack the practical experience to land a meaningful job in the tech industry - even though you’ve studied a lot of Computer Science at the University or in an alternative way -, you’ll probably want to start working at a side project.
Why? Because it can offer you a lot of benefits!

Here’s a brief list of pros that should give you the idea of why side projects are useful:

• you have the opportunity to learn a lot while enjoying the relax of having no deadlines
• you can focus on what you like most, or even automate a task that you spend a lot of time on
• you can even give a boost to your tech career, enriching your portfolio with projects different than the hated “Todo list” / “Tic tac toe” / “Random abused tutorial project”

In this article I’d like to offer you an overview of what I did, hoping to inspire someone else to follow the same guidelines.

First step: find something broken to fix

In my opinion, the best way to get started is to come up with an idea that can help you or somebody else. Usually this is an easy step, and the fact that it shouldn’t take you too long is really important: if you spend too much time on something, without having anything concrete, you’ll probably end up with a lot of code that will never see the light of a release. Start with something that has a well-defined purpose, and maybe expand it after its first release. You don’t necessarily need to create the new Airbnb or Pinterest to be satisfied of your petty project.

The problem that I’ve (rather successfully) tried to solve is the following: I wanted to be able to find all the files that contained a certain pattern in their content, be it a word, a programming language keyword, or a complicated Regular Expression. I’m pretty certain that this could be easily achieved with tools such as grep and awk, but:

• I don’t really appreciate the jargon this commands imply
• I spend way more time on Windows than on a UNIX like environment such as Ubuntu or Mac OS
• the main point of a side project is to build something on your own

Second step: decide what instruments / APIs to use

I spent quite some time with NodeJS, ever since I’ve heard about it at High School. Now that I’ve been working as a Full Stack Developer at Brainwise.it since Summer 2016, I’ve come to know a lot of tricky aspects of the V8 runtime and Node’s APIs, but I’ve never had the occasion to fiddle with the Stream APIs.

Since NodeJS is the environment I’m most comfortable with (followed by Golang) and due to the fact that I needed to scan a lot of files, using it as the foundation of my petty project resulted pretty natural to me.

Also, I kind of suffer the fact that JavaScript lacks typings (using also Golang a lot, I find them fundamental in a great deal of different ways), so I’ve decided to try the latest TypeScript version.

Third step: decide the aspect of your application

Note that by “aspect” I don’t necessarily need to think about the UI layer. I’m mainly talking about deciding how you want to interact with the app. Should it be a mobile application? Or a web one? Or even a desktop app?
To keep things simple and slim, I’ve decided to follow the CLI way. Also, I wanted the terminal UX to be colorful and informative in a clean fashion: command line doesn’t necessarily need to be so grey and retro as we’ve come to expect it.

Fourth step: if there’s something you can reuse, reuse it

Since my main focus was handling tons of file scans as fast as possible, I didn’t really want to think about how to render colorful progress output in the CLI or how to filter files via glob patterns as a UNIX shell would do. So I ended up using the following amazing npm packages:

• chalk: for rendering cheerful colors in the terminal
• progress: to provide meaningful output to the user while the app is processing files
• yargs: to parse command line options
• glob: to match file names as a shell would do

Fifth step: enjoy the realization of your project and profit from what you learn in the process!

This is the step in which you have to show the world (and potential future colleagues, or even employees) what you’re able to do.

If I had to sum up which skills I’ve enhanced and what I’ve learnt, it’d be the following:

• if a module’s TypeScript definition hasn’t been posted on DefinitelyTyped, you have to create it yourself. Pro tip: if you extend an open source project, you should contribute back
• I learnt how to create generic functions in TypeScript, which are really similar to C++ templates
• I verified personally that if you open a lot of files without closing them you’re going to have a really bad time
• I discovered that in some cases using the reduce method on an array is way more efficient than map combined with filter
• I learnt how to create a custom Buffer size while reading a Stream with fs.createReadStream. You have to use the highWaterMark property, which is barely mentioned in the official docs
• I also managed to create a small NodeJS app adjustable enough to be comfortably consumed from both the CLI and another npm module

Beside that, if you think to eventually publish your repo as a package to npm, please check if the name you chose has already been taken. Mine was. Initially my project was called “Discover”, because you know, its purpose is to discover patterns inside a specific set of files. After acknowledging that somebody else took that name before me, I ended up calling it “Pate”, pronounced like the following:

It is reasonably similar to “pattern”, also I was anxious of publishing the project, and when I’m anxious I become hungry.

You can find Pate on Github and on the npm registry. I hope this article was helpful to you, I’ve tried to write it as the post I would have wanted to read before writing this console application. If you have suggestions or comments, please post a response below, and if you liked what you read so far, smash that clap button!

Introducing Pate, my latest Open Source Side project was originally published in HackerNoon.com on Medium, where people are continuing the conversation by highlighting and responding to this story.

One of the most annoying things that can happen while developing a React Native app is the dreaded A problem occurred configuring project ‘:app’ error, immediately followed by a more specific The SDK Build Tools revision (xx.x.x) is too low for project ‘:your-react-native-dependency’ message.

This may occur in a variety of different situations:

• You ran react-native run-android after having updated a specific native dependency;
• You ran the same command after having simply run yarn, which internally removes every manual update you may have done to the files in the node_modules folder (besides actually updating every dep);
• You tried to link a native module without success (either with react-native link your-react-native-dependency or manually);

Probably you already know how to fix this manually, but chances are you’re looking for a way to automatize it, not to waste precious minutes every day.

Well, after this article you’ll know how to deal with it, for good.

One of the most annoying things that can happen while developing a React Native app is the dreaded A problem occurred configuring project ‘:app’ error, immediately followed by a more specific The SDK Build Tools revision (xx.x.x) is too low for project ‘:your-react-native-dependency’ message.

Manual solution

Honestly, I have no intention to waste your time digging into the manual solution, since there are many other tutorials online that do it pretty well (example), but all of them — at least, everyone of them I’ve managed to find — only offer a temporary solution, which you have to repeat every time you perform one of the steps above, or even worse, propose you to downgrade to an old (and slow) version of gradle, how useful can that be?

So, let’s delve into the real solution.

Automatic solution

What’s better than a simple script to change all the compileSdkVersion and buildToolsVersion entries in every react-native’s Android dependency of our project? We could write it in JavaScript and then hook it up to the scripts section of our package.json, and then invoke it from npm run or yarn run.

Well… While that could certainly be a huge step forward, we’d still have to parse the gradle files and edit them without invalidating their sintax. Nope, to solve this issue correctly and in a clean manner, we should leverage the Gradle build tool scripting language directly.

Gradle’s Project API has a method called afterEvaluate whose description is the following:

void afterEvaluate(Closure closure)

Adds a closure to be called immediately after this project has been evaluated. The project is passed to the closure as a parameter. Such a listener gets notified when the build file belonging to this project has been executed. A parent project may for example add such a listener to its child project. Such a listener can further configure those child projects based on the state of the child projects after their build files have been run.

You can basically think of it as React’s componentDidMount on steroids.

The right place to call this method is in your yourReactNativeProject/android/build.gradle file, inside the subprojects {} section.

Your build.gradle file should look like the following:

Now, let’s add the subprojects {} section and invoke our script:

What did we just write? We basically delegated to Gradle the task of overwriting two particular entries of the ‘android’ property of every dep’s build.gradle file: ‘compileSdkVersion’ and ‘buildToolsVersion’.

(I know, all these files have the same name and extension, it can be quite confusing for newbies).

You should obtain the following result (more or less) for every native dependency of your React Native Android project.

That’s it, simple as pie. I personally love when a tedious issue can be fixed in a handful of lines of code.

You may also be interested in: React Native on XCode Beta 8.0: how to fix initial build error.

Some of my open source libraries I’d love to hear feedback about:

• https://github.com/jkomyno/react-native-animated-hide-view
• https://github.com/jkomyno/react-native-animated-checkbox
• https://github.com/jkomyno/react-native-universal-picker

If you liked this tutorial and want to keep learning about React Native tips and tricks, make sure to click the “Follow” button below, and follow me on Github at @jkomyno

I mean, do you remember how not-so-pleasing it was to write old school JavaScript, mocking what now are proper classes and adding quite a lot of boilerplate when what you just needed was returning a value of a function? Now, a lot of front end apps (or even boilerplates such as ) are written in ES6/ES7 by default and then transpiled into browser-compliant ES5 by BabelJS, but what about server programming in NodeJS?

babel-node

Actually, the guys at Babel have built a nice tool which accomplish with need, called babel-node. But is it suitable for production environments? You know, this alert isn’t exactly production-friendly…

You should not be using babel-node in production. It is unnecessarily heavy, with high memory usage due to the cache being stored in memory. You will also always experience a startup performance penalty as the entire app needs to be compiled on the fly.

Yes, you can actually use it in a production environment, although you definitely need to tweak here and there a little bit. As Babel itself points out, babel-node is not meant to be used in production. “Wait” — you may say — “how come it’s like that?”

It’s actually pretty simple:

1. Transpile the code first with babel
2. Execute the transpiled code directly with node

You see, splitting the task in two allows us to avoid the just-in-time transpile overhead.

Let’s get to code

First of all: move all the NodeJS files you use server-side into a directory, eg. server.

Here’s my setup.

• build: generates the transpiled version of your server file (the -d option indicates the output directory)
• prebuild: clears the build directory
• start: executes the transpiled code in production mode
• prestart: calles the previous defined “build” script

"build": "babel -d ./build ./server",
"prebuild": "rm -rf build/*",
"start": "NODE_ENV=production node ./build/index.js",
"prestart": "npm build"

Please let me know if this was useful to you. You can find me both onGithub and Twitter.

This is especially true for Node.js/npm newbies, who often try the most popular packages installing them globally, without even defining them in their package.json files; however, this may be useful even for more advanced Node.js developer, who may not know every npm CLI trick.

So, this is it:

Let’s break this line down a little bit, shall we?

• npm: the Node package manager command line tool
• list -g: display a tree of every package found in the user’s folders (without the -g option it only shows the current directory’s packages)
• — depth 0 / — depth=0: avoid including every package’s dependencies in the tree view

Here’s a sample result:

Congratulations, you now know how to get a list of all the npm packages you have installed on your machine!

If this article helped you, consider subscribing to get my latest tutorials and thoughts about software engineering. If you like to experience Medium yourself, consider supporting me and thousands of other writers by signing up for a membership. It only costs $5 per month, and you get the chance of making money with your writing as well. You can cancel the membership anytime. By signing up with this link, you’ll support me directly, and it won’t cost you anything more. If you do so, you’ll encourage me to dedicate more time to knowledge sharing, so thank you a lot!

Let’s get in touch on Twitter, Github, or LinkedIn. My DMs are open, come to say hi 😊

This is exactly what happened to me some hours ago, when I crossed the hard path of installing wmic (Windows Management Instrumentation Command-line) on a GNU/Linux machine, which I needed for an enterprise application’s backend. Yeah, I know, it may sound strange to use wmic on a non-Microsoft environment, but our test machines run Ubuntu 16.04 and our production environment consists of a set of SUSE Linux Enterprise Server 11, and adding another virtualization layer wasn’t an option.

First of all, you have to be sure to install the autoconf package.
For Debian/Ubuntu/etc:

$ sudo apt-get install autoconf

For Suse:

# zypper install autoconf

The common way of instaling wmic can be resumed in this gist:

Plain old bash shell right? Right, but if you try to run this script on a not-so-frequently updated system it’ll complain that he couldn’t achieve the installation during the sudo make execution. Here’s the summary of the failed-installation log:

Admit it, everyone hates when build from source fails. So, what’s the source of this failure?

If you take an accurate look at this part of the log (it’s only 35 rows long, don’t be lazy) you can find this specific line, which gives us the most precious debug info we could have ever desired:

Can’t use ‘defined(@array)’ (Maybe you should just omit the defined()?) at ./pidl/pidl line 583.

That “pidl” file at “wmi-1.3.14/Samba/source/pidl” is a perl source file which apparently doesn’t seem to have the most standard compliant code. After having googled for quite some time, I found this page in the official Perl Language Website. Here’s what I was looking for:

Can’t use ‘defined(@array)’ (Maybe you should just omit the defined()?)

(F) defined() is not useful on arrays because it checks for an undefined scalar value. If you want to see if the array is empty, just use if (@array) { # not empty } for example.

I haven’t ever used Perl, but the instruction at line 583 of the “pidl” file seemed useless to me, so I just got rid of it and saved.

The fastest way of doing this simple task is executing the following command on the terminal (this is particularly useful is you are in an SSH session):

sudo sed -e ‘583d’ pidl > pidl

What next? Simply re-execute the prior “sudo make” command and you’re done!

Please let me know if this was useful to you. You can find me both on Github and Twitter.

This means that sometimes you developers need to tinker with some parts of the projects generated by the npm package to make it work, but that basically happens with every beta application.

The latest issues I experienced with React Native took me some time to find a decent solution, and given the fact that many questions on StackOverflow are related to this problem, I’ve decided to write the simplest solution I’ve come up with.

Environment

First things first:

• Mac OS version: El Capitan 10.11.6 (you may have problems installing XCode 8.0.0 Beta on a lower version)
• node -v: v6.5.0
• npm -v: v3.10.3
• react-native-cli -v: 1.0.0
• react-native@0.32.0

Now, this issue (related to a RCTWebSocket’s error inside the “ios” folder in the react native project) exists due to the fact that the newest XCode version adds some default flags before the first compilation, and React Native hasn’t kept up with these latest changes yet. Let’s help the developers then, waiting for an official solution from the React Native Team at Facebook!

Project setup

Simply run the same ol’ terminal commands:

$ react-native init YourAwesomeProject

$ cd YourAwesomeProject

$ react-native run-ios

Now, here’s the log I had (not that ugly ** BUILD FAILED ** at the end):

You get the same problem if you try to run your iOS app directly from XCode either.

Enough, what’s the solution?

Here’s how to fix this annoying problem! Start by opening your project on XCode, then:

• head over to the RTCWebSocket project (in the TARGETS section)and double click it;
• in the build settings tab, select both “All” and “Combined” views
• look for “Apple LLVM 8.0 — Custom compiler flags”
• in the “Other C/C++/Warning flags” subsection just double right click and click, select the list entries and delete them tapping on the “minus” icon (please see the video below)
• click the run button (or press ⌘+R)
• you’re done!

https://webmshare.com/play/ovaE6

Thanks for having taken a look at this article, the first I’ve ever written here on medium.com! You can find me both on Github and Twitter.