DEV Community: Nikola Stojaković

Automate boring tasks with scripts in a Node project

Nikola Stojaković — Sun, 04 Jun 2023 18:18:07 +0000

One of many things I like about Rails is it's CLI. Scaffolding, generating migrations, creating various types of resources for the application and other stuff is so neat and it's no wonder many frameworks copied it shamelessly.

Once project grows beyond certain point, doing routine tasks becomes tedious. When this happens, I write scripts to automate various jobs. It really helps in maintaining productivity and focusing on important stuff.

Here is a quick way how to do this on any Node project if your framework of choice doesn't already provide some way to write custom commands for the CLI. After we're finished you would be able to do something like this:

npm run script generate migration <migration_name>

Create shell script which will serve as an entry point. I typically put it in src/scripts along with the modules of the scripts I'm going to create. Let's call it entry.sh. Don't forget to allow execution of this script with chmod.

#!/usr/bin/env bash
/usr/bin/env node --no-warnings --experimental-specifier-resolution=node ./src/scripts/entry.js "$@"

In your package.json add NPM script which will be used for running our custom scripts.

{
  "scripts": {
    "script": "./src/scripts/entry.sh" // our NPM script
  },
}

Create entry.js file which will serve as the processor for arguments we'll pass.

import { createMigration } from './migrationManager';

// First two arguments are path to the Node executable and path of this file respectively; let's just ditch them
const usefulArguments = process.argv.slice(2);
const [first, second, ...rest] = usefulArguments;

if (['g', 'generate'].includes(first)) {
  if (second === 'migration') {
    createMigration(...rest);
  }
}

I'm keeping things very simple intentionally; once your list of scripts grows you'd probably like to use some arguments parser for better organization and documentation (e.g. commander, yargs, argparse...).

Support for TypeScript and path aliases

If you've been concerned about the .js extension because your project is using TypeScript don't worry - there is a way to do this with support for TypeScript and path aliases (if you're using them in your project).

We'll need to install few development dependencies before we continue with the process.

npm install ts-node tsconfig-paths -D

Create a scriptsLoader.js file in the root of your project. This will ensure that your scripts written in TypeScript could be executed and that paths using aliases defined in tsconfig.json will be properly resolved.

import { resolve as resolveTs } from 'ts-node/esm';
import * as tsConfigPaths from 'tsconfig-paths';
import { pathToFileURL } from 'url';

const { absoluteBaseUrl, paths } = tsConfigPaths.loadConfig();
const matchPath = tsConfigPaths.createMatchPath(absoluteBaseUrl, paths);

export function resolve(specifier, ctx, defaultResolve) {
  const match = matchPath(specifier);
  return match
    ? resolveTs(pathToFileURL(`${match}`).href, ctx, defaultResolve)
    : resolveTs(specifier, ctx, defaultResolve);
}

export { load, transformSource } from 'ts-node/esm';

Update NPM script so we can pass path to the loader we've just made.

{
  "scripts": {
    "script": "./src/scripts/entry.sh ./scriptsLoader.js"
  }
}

Update src/scripts/entry.sh to pass path to the loader.

#!/usr/bin/env bash

all_args=("$@")
loader_path="$1"
rest_args=("${all_args[@]:1}")

/usr/bin/env node --no-warnings --experimental-specifier-resolution=node --loader "$loader_path" ./src/scripts/entry.ts "${rest_args[@]}"

And that's it!

Iteration protocols in JavaScript

Nikola Stojaković — Sun, 08 Aug 2021 18:38:46 +0000

No matter on which level you are as a JavaScript developer, you have used iterators and iterables so far, even though you may haven’t been aware of that. But what exactly they are and what’s their purpose?

Iterables

Each object which implements @@iterator method (expressed via [Symbol.iterator]) is an iterable. It serves as a definition for the behavior which object will have when it’s iterated on (for example with the for...of statement). There are built-in iterables like String, Map, Set, Array, TypedArray and others but you can build your own too.

let runningStats = {
  Mike: 6,
  Emma: 9,
  Billy: 11,
};

// creates an iterable which will return custom objects
runningStats[Symbol.iterator] = () => {
  let i = 0;
  const pairs = Object.entries(runningStats);

  return {
    next: () => {
      // signal that iterating has been finished
      if (i === pairs.length) {
        return { value: undefined, done: true };
      }

      let currentPair = pairs[i++];

      return {
        value: { name: currentPair[0], kilometers: currentPair[1] },
        done: false,
      };
    }
  }
};

for (const personStats of runningStats) {
  console.log(personStats);
}

Which will give us the following output:

{ "name": "Mike", "kilometers": 6 }
{ "name": "Emma", "kilometers": 9 }
{ "name": "Billy", "kilometers": 11 }

Therefore, we can say that iterable is each object which conforms to the iterable protocol described above. You can look at the protocols as some kind of interfaces. And since strings and sets for example are already iterables, you can iterate over them without defining [Symbol.iterator] method:

const str = "word";

for (const char of str) {
  console.log(char);
}

const set = new Set([1, 1, 2, 2, 3, 3]);

for (const number of set) {
  console.log(number);
}

Output:

w
o
r
d
1
2
3

Fun fact: Set and various other iterables accept iterables as an argument. You would be able too see it in the Set example above by passing a string or a map. Sometimes there are limitations though – Map for example accepts only array-like iterables.

Iterators

If you take a closer look at the example of the iterable above you’ll see that we return an object with the next() method. That object is an iterator. Of course, not every object which has the next() method is an iterator. Your method needs to return an object which contains at least following two properties; value (any JavaScript value) and done (boolean). Not doing so would result in a TypeError when the method is called. This is called iterator protocol.

Let’s see how we can get the iterator from the iterable we made above.

const iterator = runningStats[Symbol.iterator]();

console.log(iterator.next()); // { value: { "name": "Mike", "kilometers": 6 }, done: false }
console.log(iterator.next()); // { value: { "name": "Emma", "kilometers": 9 }, done: false }
console.log(iterator.next()); // { value: { "name": "Billy", "kilometers": 11 }, done: false }
console.log(iterator.next()); // { value: undefined, done: true }

// Any subsequent calls of the next() method will return the same result
console.log(iterator.next()); // { value: undefined, done: true }

Using iterators directly like this could be useful when we want to skip certain element(s) when looping over an iterable.

const food = ["carrot", "apple", "banana", "plum", "peach"];

const iterator = food[Symbol.iterator]();
iterator.next(); // skip the first one

for (const fruit of iterator) {
  console.log(fruit);
}

Which would give us the following output:

apple
banana
plum
peach

Infinite iterators

You don’t need to impose limits on the number of elements in your iterators. Sometimes it’s useful to have infinite iterators which we can use multiple times.

const infiniteList = (start) => {
  let value = start;

  return {
    next: () => ({ value: value++, done: false }),
  };
}

const iterator = infiniteList(6);

for (const _ of new Array(100)) {
  iterator.next();
}

console.log(iterator.next().value); // 106

Okay, so let’s try to use for...of statement to loop over this iterator – at the end, it’s more elegant, isn’t it?

const infiniteList = (start) => {
  let value = start;

  return {
    next: () => ({ value: value++, done: false }),
  };
}

const iterator = infiniteList(6);

for (const element of iterator) {
  console.log(element);
}

And run it...

Oops! Looks like we got an error. It says iterator is not iterable. What’s going on?

Differences between iterators and iterables

We saw from the example with the food array that iterator was usable both by calling next() method and inside for...of statement. So, why our iterator doesn’t work like that? Well, it’s because not every iterator is iterable.

Remember that the iterable protocol says that we need [Symbol.iterator] method on our object for it to be iterable? The thing is that standard iterators have it and it looks like this:

[Symbol.iterator]() {
  return this;
}

So handy, isn’t it? That means we can just add it to our iterator to make it an iterable. Oh, and while we’re at it, let’s change the iterator to be finite to avoid our tab crashing like the Dogecoin in May.

// use non-arrow function syntax so that this won't return value of the outer scope
const finiteList = function(start, end) {
  let value = start;

  return {
    next: () => {
      if (value === end) {
        return { value: undefined, done: true };
      }

      return { value: value++, done: false };
    },
    [Symbol.iterator]() {
      return this;
    }
  };
}

const iterator = finiteList(6, 16);

for (const element of iterator) {
  console.log(element);
}

Output:

Voilà! We made an iterator which is also an iterable.

Fun fact: There is another way to make our iterator iterable by inheriting from %IteratorPrototype% object, however, this way is too cumbersome.

Thankfully, there is even easier way to create iterable iterators.

Generators

ES6 introduced generator functions which are functions returning special kind of iterator – Generator. Generator adheres to both, iterator and iterable protocol. You’ll recognize them easily by the asterix (*) sign before their name. Let’s see how both, finite and infinite list functions from above would look like when written as generator functions.

function* infiniteList(start) {
  let value = start;

  while (true) {
    yield value++;
  }
}

const infiniteIterator = infiniteList(6);

console.log(iterator.next().value); // 6
console.log(iterator.next().value); // 7
console.log(iterator.next().value); // 8
console.log(iterator.next().value); // 9

function* finiteList(start, end) {
  let value = start;
  while (value < end) {
    yield value++;
  }
  return value;
}

const finiteIterator = finiteList(6, 16);

// skip 4 steps
for (const _ of new Array(4)) {
  finiteIterator.next();
}

for (const num of finiteIterator) {
  console.log(num);
}

Step by step description of what happens;

Generator function is called, returning a Generator object
Calling next() method executes it until yield occurs.
yield defines a value which will be returned. Once yield is reached, execution at that point stops and all variable bindings are saved for the future calls.
Each subsequent next() call continues execution from the last reached point.
return from a generator function says that it’s a final value of the iterator.

Let’s give another, more straightforward example;

function* lilIterator() {
  let value = 0;

  yield value++;
  yield value++;
  yield value++;

  return value;
}

const iterator = lilIterator();

// next() is called, execution is stopped at the first yield which returns 0, value is now 1
console.log(lilIterator.next().value);

// next() is called, execution is stopped at the second yield which returns 1, value is now 2
console.log(lilIterator.next().value);

// next() is called, execution is stopped at the third yield which returns 2, value is now 3
console.log(lilIterator.next().value);

// next() is called, at this point generator function has return which means that iterator will be finished with value 3
console.log(lilIterator.next().value);

// any subsequent next() calls will return { value: undefined, done: true }, so output here would be undefined
console.log(lilIterator.next().value);

If we didn’t add return statement at the end of the generator function, iterator would finish after the third yield. And since in our example for infinite list we had yield inside while(true) {} loop, we ended up with an iterator which returns values infinitely.

Conclusion

I hope this article helped you to get a better understanding of iteration protocols. There are some stuff I didn’t mention (like using yield* for delegating to another generator function) because they wouldn’t add much point for the article. I encourage you to experiment on your own and practice these concepts in your spare time. I showed you some small examples but iterators are much more powerful than that – you’ll see this as you progress in your career (if you haven’t already).

Let’s sum up the key points;

Iterable is an object which adheres to the iterable protocol, meaning it has a [Symbol.iterator] property whose value is a method returning an iterator.
Iterator is an object which adheres to the iterator protocol, meaning it has a next() method which returns an object with at least value and done properties.
Iterator can but doesn’t have to be an iterable.
We can use generator functions for creating objects adhering to both, iterable and iterator protocol.

7 interesting deprecated JavaScript features

Nikola Stojaković — Wed, 04 Aug 2021 17:29:55 +0000

Since it’s birth 26 years ago at Netscape, JavaScript has come a long way. A language which was used only to interact with Java applets and do simple DOM manipulation is now used for writing back-ends and desktop and mobile applications too. Ecosystem grew by a big margin as well as the community. Just like every other language, JavaScript had (and still has) rough edges and quirks. We’re stuck with some of them because of the backward compatibility. Some are, (un)fortunately, mostly or completely gone. Some of these can still be used but it’s highly discouraged.

`Object.prototype.watch` and `Object.prototype.unwatch` methods

Unce upon a time there was an easy way to watch for the property changes on an object.

var cat = {};
cat.watch("name", function (propertyName, previousValue, newValue) {
  return "Mr. " + newValue;
});

cat.name = "Oswald";
console.log("Hello " + cat.name + "!"); // Hello Mr. Oswald!

cat.unwatch("name");

cat.name = "Luna";
console.log("Hello " + cat.name + "!"); // Hello Luna!

Alternative

Nowadays you can use Proxy for this purpose.

const handler = {
  set: (obj, prop, value) => {
    if (prop === 'name') {
      obj[prop] = `Mr. ${value}`;
    }
  }
};

let cat = new Proxy({}, handler);

cat.name = "Oswald";
console.log("Hello " + cat.name + "!"); // Hello Mr. Oswald!

cat = { ...cat }; // this will remove behavior imposed by Proxy

cat.name = "Luna";
console.log("Hello " + cat.name + "!"); // Hello Luna!

`with` statement

We all know how horrible working with long chain of properties can be. Fortunately, there is a way around it. Unfortunately – you shouldn’t use it.

const cat = {
  details: {
    passport: {
      location: {
        city: 'New York'
      }
    }
  }
};

with (cat.details.passport.location) {
  city = 'Meowyork';
}

There are two reasons why you shouldn’t use with statement.

There is no place for optimization inside it, since you can’t predict if variable will refer to a property or to an outside variable.
It violates lexical scope, making program analysis very hard or even infeasible.

Also, it will be impossible for you to use it in ES6+ (or ES5 with the strict mode turned on). Strict mode prohibits it’s usage.

Alternative

The best you can do is to declare a variable which will hold the chain of properties instead.

const cat = {
  details: {
    passport: {
      location: {
        city: 'New York'
      }
    }
  }
};

const catLocation = cat.details.passport.location;
catLocation.city = 'Meowyork';

Expression closures

Long before arrow functions were even in a plan, there were expression closures. They allowed you to omit curly braces and return statements from the method definitions completely.

var cat = function() "Luna";

var favorites = {
  food: function() "Tuna"
};

Alternative

This has been removed in favor of using standard ES syntax.

var cat = function() { return "Luna"; }

var favorites = {
  food: function() { return "Tuna"; }
};

Nowadays you can also use arrow functions and method definitions (both introduced in ES6).

const cat = () => "Luna";

const favorites = {
  get food() { return "Tuna"; }
};

`Object.observe` and `Object.unobserve` methods

Back in the days there was also an easy way of getting an information about any changes to an object.

var cat = {
  name: "Oswald"
};

Object.observe(cat, function(changes) {
  console.log(changes);
});

cat.name = "Luna";
// [{ name: 'name', object: <obj>, type: 'update', oldValue: 'Oswald' }]

Object.unobserve(cat);

cat.name = "Max";

There were the similar methods for arrays too – Array.observe and Array.unobserve.

Alternative

You can do this with Proxy too.

const cat = new Proxy({ name: "Oswald" }, {
  get: (target, prop) => {
    console.log({ type: "get", target, prop });
    return Reflect.get(target, prop);
  },
  set: (target, prop, value) => {
    console.log({ type: "set", target, prop, value });
    return Reflect.set(target, prop, value);
  }
});

cat.name = "Luna";
// { type: 'set', target: <obj>, prop: 'name', value: 'Luna' }

cat.name;
// { type: 'get', target: <obj>, prop: 'name' }

`let` expressions and `let` blocks

In ES6, two statements for declaring block-scoped variables have been introduced; let and const. For the brief period of time, there were non-standard extensions to the let statement. These were let expressions and let blocks.

let blocks provided a way to instantiate a block where variables can have different values, without affecting the same-named ones outside of that block.

var catName = "Oswald";
var catAge = 2.5;

let (catName = "Luna", catAge = 2) {
  console.log(catName + "(" + catAge + " years old)"); // Luna (2 years old)
}

console.log(catName + "(" + catAge + " years old)"); // Oswald (2.5 years old)

let expressions did the similar thing but on the expression level.

var catName = "Oswald";

let(catName = "Luna") console.log(catName); // Oswald

console.log(catName); // Luna

Alternative

Since let is block scoped you can just declare variables again inside inner scope and change them there.

let catName = "Oswald";
let catAge = 2.5;

{
  let catName = "Luna", catAge = 2;
  console.log(catName + "(" + catAge + " years old)"); // Luna (2 years old)
}

console.log(catName + "(" + catAge + " years old)"); // Oswald (2.5 years old)

HTML wrapper methods on strings

They are basically bunch of methods which wrapped your string with tags like bold, blink, font, small, big, i etc.

"Some teeny-tiny text".fontsize(3);    // <font size="3">Some teeny-tiny text.</font>
"Some tiny text.".small();             // <small>Some tiny text.</small>
"Some yuuuge text.".big();             // <big>Some yuuge text.</big>
"Talk to the hand!".bold();            // <b>Talk to the hand!</b>
"You have been terminated.".blink();   // <blink>You have been terminated.</blink>

Alternative

There are no alternatives for this monstrosity.

`ParallelArray`

This one was an experimental feature introduced by Mozilla in the Firefox (specifically, version 17 of the Gecko engine). It’s purpose was to enable data-parallelism by executing multiple functions in parallel. If it wasn’t possible, they would be executed in the sequential order.

var cats = new ParallelArray(["Oswald", "Luna", "Max"]);
cats.map(function(name) {
  return "😸 " + cat;
});

Alternative

Today you can use Promise.all to accomplish this.

Conclusion

It’s fantastic to see how much JavaScript has progressed for the last 26 years. Who could’ve thought that language made in 10 days can become one of the most dominant in the industry? I believe it’s a good practice to take a step back and see how things worked in the past. That can teach us not to repeat the same mistakes anymore. It can also make us more grateful for the things we have today. Even though I have a fair share of criticism for JavaScript, I can’t wait to see what’s coming in the next two decades.

Why our software is broken?

Nikola Stojaković — Sat, 19 Dec 2020 14:08:47 +0000

Long time no see! Since May when I wrote my last post, many things happened in my life. I started living alone, moved to a new city and found a new job. I think I had pretty good rest from the writing. Today, I’ll write about a topic which interests us all; C-level staff, developers, managers, end users… Recently, I watched an amazing talk by Joe Armstrong in which he presented quite interesting and a bit controversial thought;

Computer science is confusing because it’s not a science and there are too many ideas floating around.

I sincerely believe this can explain lot of issues in software development currently. We’re constantly trying to improve quality of our software, lower the time it takes to build it and prevent bugs. When confronted with the question how to build a quality software, different people will give you different answers. Some hardcore FP enthusiasts will try to persuade you to rewrite whole your back-end in Haskell. That person in the corner will swear by TDD. A manager on the third floor will say we should ditch agile and use waterfall.

Most people are missing a huge factor here; a failure to reduce complexity.

Personal experience

In the company I worked in the past, we received a new project which had to be done in React. At that time I had a bit of experience with React and understood basic ideas behind it. There was another colleague on that project who almost never worked with React before. Right at the start, we received a task to create an image configurator. On the surface, it was basic; you could choose colors, icons, text font and other stuff. What made it quite complex was a bad design. Instead of using states, my colleague (understandably, since he worked mostly with jQuery before) did direct mutations on the DOM. If you worked with React seriously, you know this is a big no-no.

Unfortunately, this part grew and became harder and harder to maintain, to the point where we spent half an hour fixing some trivial issue. This was the first time in my career where I saw how important it is to try to reduce complexity as much as you can. Sometimes we tend to go too far when we’re solving particular problem. Always keep in mind that you’re writing for other people first, and then for the machine. Machine won’t maintain your code; you’re the one who will have to explain it to others. Even if you leave the company before that, don’t do something you won’t like to experience yourself.

Alright, but how can I reduce complexity?

Now, there is a catch. Unfortunately, it’s possible to reduce complexity of your code only to some degree. Software is inherently complex on it’s own. It has to take inputs, handle edge cases and errors, work with files and data received over the network, draw things on the screen and many other stuff. We’re developing on the machines which are dozens of times more powerful than the ones used fifty years ago. On top of that, you have deadlines, poorly documented libraries, legacy code etc. It’s understandable why software development today is much more challenging in many ways.

Don’t try to appear smart. If there is a simple way to solve particular problem which works and is easy to understand, use it. Don’t build unnecessary abstractions and features no one asked for. Use descriptive variable and method names. It’s much smarter to write code which is easy to understand and maintain than something which only you will understand.
Write documentation. Even you won’t be able to understand some parts of your code after some period of time. Describing what some part of your code does will help other people working on your code and it will help you later as well.
Write tests. Sometimes, writing a test before you start implementing certain feature will help you to better design it.
Ask yourself do you really need it. I can’t find that article now, but I think it was written by Joel Spolsky, ex-CEO of StackOverflow. I use it as my guiding star and I think about it whenever I’m starting to work on a new side project. In essence, it says this; your job is not to write the code, but to solve problems. Ideally, you should solve them without writing any code. Most of the time it’s not possible though, so you should strive to write least possible amount of it which will be both, well working and understandable.

There are many other ways but these are some of the most important ones. Remember, it’s always about balancing. Adding new features will definitely make a whole system more complex, but that doesn’t mean we shouldn’t add new features at all. It means we should be more careful when doing so, taking into account the most important things; value it gives us (both in the short-term and long-term) as well as the effort it takes to be built and maintained.

Things should be as simple as they can be, but not simpler than that

I’m using this Einstein’s quote fairly often when I’m talking about software development. It’s so amazing because it can be applied across many different fields. Reducing complexity in the project shouldn’t mean oversimplifying stuff. As I said, software is inherently complex on it’s own; trying to simplify something too much will have the opposite effect. For example, if you’re building a web application similar to Lichess, you’ll have to think about lots of things:

fault tolerance
handling hundreds of thousands of concurrent users
streaming
security

And so on and so on. As long as you can have controlled complexity in the project, it’s okay for it to exist in the project. Controlling complexity means building a flow which will help new developers to learn how the system works so they can make contributions to it. Most obvious tool for that job is writing documentation. In an article The Plea for Lean Software written by Niklaus Wirth, creator of Pascal, he says something which was proven to be true more than two decades later:

The belief that complex systems require armies of designers and programmers is wrong. A system that is not understood in its entirety, or at least to a significant degree of detail by a single individual, should probably not be built.

To sum up; it’s okay for some things to be complex. What you should prevent though is for things to become so complex that adding each new feature will take significant amount of time. This will make maintenance of the software painful and lead to even higher complexity in the future. The initial effort of implementing a feature is not as important as the effort of maintaining it.

Conclusion

I intentionally made this article smaller than I planned to. My goal was to motivate you to think about this more. We’re witnessing enormous expansion of the software and I believe this topic will be even more relevant in the future. I’ll leave you to think more about this on your own and to do your own research on this problem. Before that, I’ll recommend you an amazing book I recently read; Code Simplicity: The Fundamentals of Software by Max Kanat. It’s only 80 pages long but contains lot of valuable information on reducing software complexity and overall proper software design. I’ll suggest you to read it and take notes. No matter which technology you use or how your projects will look, these points will be helpful to you for the rest of your career.

Frequent questions about programming answered

Nikola Stojaković — Thu, 07 May 2020 15:53:27 +0000

With the growth of elitism and fanboyism in software development world, as well as many questions I noticed all over the web showing fundamental misunderstanding about this topic, I felt the urge to write this article. You’re free to contribute, fix mistakes and add your own opinions. Goal of this article is to answer the most frequently asked questions about software development.

You’re completely free to share this article or parts of them as long as you share the source too. I will occasionally update it with new questions and answers. Questions have quite mixed up order, but I hope you'll be able to find the answers you need. I will try to organize them better in the future.

Initial version of this article was written on Quora so you will see few links to the answers from Quora.

What kind of equipment do I need to start with programming?

Any decent computer will do the job.

See: Garry Taylor's answer to What equipment do you think is the most important for being great a programmer?

Which programming language should I learn first?

In my opinion, your first language should be:

easy to learn
have a strong community so you can get your answers easily
a language with many jobs available to you

The most obvious choices in that case are Python, Ruby, JavaScript or PHP. All of them are easy to learn, have strong community behind them and there is a plethora of jobs for them.

Do I need to be a great mathematician to become a programmer?

It depends on your field of work. For most of the things (web, desktop and mobile development), strong math background is not required. Exceptions are game development (but you can develop simple games without strong math knowledge), machine learning, data science, cryptography etc. Even then you will most probably need knowledge in some specific fields of math.

See: What areas of computer science/programming/software development require a good math background?

Do I need to know X text editor / IDE to become a great programmer?

No. This is one of those annoying polemics where some people love to think highly of themselves because they use certain tools in development. Use whatever allows you to write applications. It doesn’t matter if it’s Sublime, Atom, TextMate, Vim, Emacs or anything else capable of editing source code.

This is, of course, exception for platform-specific developers; for example, if you’re developing for Windows it’s recommended to be familiar with Visual Studio and, if you developer for iOS / Mac, it’s recommended to be familiar with XCode (and most of the time, you have no other choices). For everything else, it doesn’t really matter.

I just graduated from the university, how can I find a job?

Finding a first job in the industry can be quite hard. Don't worry though - finding a job is easier than it was in the past.

The first thing you should do after graduation (if you haven't already) is to build a good portfolio. No one will expect it to be amazing so it's enough for you to have few projects you can show you to the potential employers.

If you don't have any idea, here are some nice lists of project ideas you can try to implement:

Post your projects on the GitHub and attach the link to your GitHub profile in your CV. Google for the software development job boards in your country and look for the internships or the junior developer jobs. Don't worry if you don't know all the things listed on the job post. Be persistent and eventually you'll land the job.

Is Java slow?

No. Right now we’re in 2020, not in 1995. JVM is developed by some really badass software engineers who know what they’re doing much better than those who call languages slow. If your application is slow, shame on you, it’s not the problem of Java (or you’re trying to do something for which Java isn’t made for, like, developing OS in Java, which, again, is not the problem of Java itself).

Is Java dead?

It looks like it’s dying last 22 years. It’s kinda hard to kill someone who owns the top place for decades.

Again, no.

What’s the best programming language ever?

This is like asking what’s the best tool ever. Seriously, do you really think that hammer is better than a screwdriver or a saw? Same thing with languages.

If language X is suitable for your project, use it. If you don’t know it, see if there are other languages suitable for your project which you already know.

In case you find the more suitable language you already know, use it. If there is no such language, learn one which is suitable for your project.

Is X programming language dead?

If there is need for developers to maintain projects written in X programming language, that language is not dead. Cobol was invented almost sixty years ago and it’s still relevant and used by many institutions (this doesn't mean it's a good idea to learn it today though).

Is X programming language bad?

Language can have some weird design choices of authors or it can have some quirks and weird behaviour (most notable ones are PHP and JavaScript), but if it does the job well, use it. If it’s bad, learn how to use it in your favor and try to avoid bad practices.

If you have no choice (e.g. JavaScript on front-end), then you need to use it.

I learned X programming language, what's the next I language I should learn?

Stop.

First, you haven’t learned A programming language. There is no way for someone to completely learn any programming language. Even if you managed to remember all of it’s keywords and the whole standard library, you still haven’t learned it.

No one cares how many programming languages do you know. As I already said in one of my previous points, languages are tools. It’s what you make with them which matters. Good engineer knows which tools are suitable for certain jobs and which aren’t.

Stop learning languages and start writing apps.

What OS should I use for developing apps, Windows, Linux or macOS?

It doesn’t really matter, except if you develop platform-specific apps. If you want to develop apps for platform X, it’s the best choice to actually do it on platform X. For iOS, it’s best to develop apps for it on macOS as primary development tool, XCode, is made for it. If platform X is Android, it doesn’t matter because ADK is available for all of these platforms (apply the same pattern for all other platforms). In other cases, it doesn’t really matter.

If you're a web developer, knowing Linux will be quite beneficial, as most web servers today use it. Don't worry if you never used it before. It's possible to play with Linux without actually installing it on the hardware (feature known as Live CD). The only thing you need is a USB stick and an ISO image of the distribution you want to try (Ubuntu will be easiest).

How much hours a day do I need to spend to learn programming?

It depends on your schedule (if you have any). There’s no definite answer for this - you should find some balance, but as it’s true with almost anything else, the more time you spend learning and practicing, the more things you will learn.

However, don’t forget that brain needs the rest too. The best way to learn new things is to practice them so, once you're finished with the basics, try to make some small projects in that language.

Why company X doesn’t rewrite it’s application in language Y but stays with language Z?

Because rewriting whole applications in other language is:

costly
time consuming
introduces possibility of new bugs

Rewriting application in another language is almost always a wrong choice. Check this article by Joel Spolsky.

Linus Torvalds said that C++ is crap, it must be true because he wrote such a big project as Linux, right?

Nope. Linus is human being and human beings, because of their imperfect nature, have their prejudices.

Check out this article: A response to Linus Torvalds on C++.

How much time does it take to learn a programming language X?

It depends on your experience. If programming language X is, for example, Haskell, which is pure functional language, and you had prior experience only with imperative languages only, you’ll have to learn completely new paradigm, not just the new language.

Learning programming languages is easy, it’s writing software which is actually hard and needs much more effort.

Do I need to have a degree to get a job as a programmer?

For some jobs, having degree in computer science will be necessary.

If you have a change to get a degree, go for it. If you don't, focus more on building your portfolio.

What topics should I study to become a great programmer?

To become a great programmer, you should have good analytical skills and know how to find the best possible way to accomplish the goal in a limited time period. There is no definite answer to this question but in my opinion, you should become familiar with this topics:

Algorithms - you don’t have to memorize them all, but you should get the idea when particular algorithm is the most suitable for your problem. You’ll learn how to implement basic once as you progress in your career.
Data Structures - you should learn their memory and time complexity and again, when particular data structure is suitable for storing certain information.
Object-oriented Programming - it’s the most important paradigm today and knowing it is mandatory.
Object-oriented Design Patterns - if you want to further advance your knowledge of OOP (as you should), design patterns are the next station for you. Again, you don’t have to memorize them but to know when certain design pattern is a good choice for organizing part of the code base.
Software Documentation - documenting your code helps you and your colleagues to better understand code base. By writing it, you’ll be thankful to yourself after few months / years as you’ll be much more able to understand what you wrote than if you left just code, without explaining what it does.
Testing - it’s often told that project which has no tests is not complete (and I mostly agree with this). By writing unit tests, you ensure that your code base is stable and ready to be extended without disastrous consequences.

You should also learn how to write clean and organized code. For this topic, I recommend a book Clean Code by Robert Cecil Martin.

This article was originally published here.

In defense of TypeScript

Nikola Stojaković — Sat, 18 Apr 2020 13:58:52 +0000

This article was originally published here.

I know what you may think now. Here we go, yet another article telling us how great TypeScript is. Why do we need to defend a language backed by Microsoft? With typings available for pretty much every popular NPM package out there? And from whom specifically? If we take a look at results of StackOverflow developer surveys for the last three years (2017, 2018, 2019), we can see that TypeScript was always in the four most loved programming languages.

While it's true that TypeScript is very popular and loved by developers all around the world, we still see misconceptions about it every day. Look - it's okay if you find TypeScript off-putting or you just don't need it. I never had to use Python in my workflow and I don't like it, but I see why people would use it. So, why do we need to talk about TypeScript?

JavaScript ecosystem has evolved

Not so long ago, JavaScript was a little more than language for showing fancy animations on the web. Nowadays, beside being used on the web, JavaScript is used for writing desktop applications (Electron), server-side applications (Node.js) and even for the IoT. Currently, there are over 1 230 000 packages on the NPM (data by modulecounts). There are many courses, tutorials and jobs for JavaScript developers out there. All in all, knowing JavaScript today is a huge advantage. This is true even if you don't plan using it as your primary language.

But things are not so great as they may look at first. We all know about node_modules jokes. With so much popularity and easiness of learning comes a bad code too. We saw that with PHP. This is not a fault of JavaScript, especially not today. As it's often the case, it's about people. Now, there are countless debates whether technology needs to set some limits to prevent the misuse or give it's users free hands. I won't open that discussion in this article. I will just try to address some common misconceptions about TypeScript.

Misconception #1 - TypeScript has no real purpose

Who knows how many times I heard this. People asking me why do they need to learn another language which basically boils down to the JavaScript. The truth is - you don't need to. It's quite possible to spend the rest of your career without ever touching any TypeScript code. But my question is why would you do such thing? Why not giving a chance to a tool which can help you to write a better software?

TypeScript definitely has it's purpose and the most important ones are;

Improving communication on the team - JSDoc is helpful, but it isn't that powerful and you need to always check the whole documentation to be sure that information in it is still valid.
Helping with refactoring - trying to change that method to return a different data in JavaScript? Pray it won't break half of your project where that method was used.
Preventing you from making dumb mistakes - adding numbers and strings, no matter how handy can be sometimes, can cause you a great pain in the long run.
Allowing you to scale your project easier - that JavaScript that scales caption you see on the TypeScript's site? Yup, it's true.

Even if TypeScript had no practical purpose, it still wouldn't be a good reason not to learn it. There are some languages (like Scheme, Haskell or Prolog) which may not get you a job[1] but will definitely expand your horizons and help you to become a better developer. Giving the fact that TypeScript is now used by many companies, there is one more reason to at least try it.

Misconception #2 - TypeScript is hard

Whether something is hard or not is pretty much subjective. In my opinion, TypeScript won't be hard to a person with solid knowledge of JavaScript. By solid knowledge, I mean you have few JavaScript application running in the production and you understand core subjects (scopes, closures, event loop, prototypes etc). If that's the case, learning TypeScript won't be a problem to you. However, if you didn't have a chance to work with static typed language before (C#, Java, C++ or similar language), it will take some time to get used to it. Again, this shouldn't be an issue because of the gradual typing.

Gradual typing allows us to slowly migrate our projects from JavaScript to TypeScript by using any in places where we're still not sure about concrete data types. Let's see it on the practical example. Here is a JavaScript method which will fetch badges of the user with specific username.

Let's say we chose to slowly migrate our project from JavaScript to TypeScript and we're turning on strict setting in our tsconfig.json like we should do. TypeScript will give us a warning for the method above:

The error above means that we have not explicitly set what type username parameter should have. When type is not set, TypeScript assumes you’d like it’s type to be any (which basically means it can be anything). Fortunately, strict option prevents us from shooting ourselves in the foot. Why? Because having implicitly set parameters throughout the project is the surest path to a disaster. As our project grows we will forget about these places and we won’t get the benefits of TypeScript’s compiler analysis. Also, it’s pretty obvious by the parameter’s name what data type we would like it to have.

Wait a second…

But what about user and badges? We certainly don’t want to use them as numbers, strings or booleans but as the objects with their respective properties and methods. For now, we will explicitly define them as any (even though we’re not required to do so). We will define badges as any[] as we know it will return array of some data type. We can also do this for parameters where we’re still not sure what data type they will have. Let’s see our refactored method now.

Now you may ask what makes such a difference between setting something as any or any[]. Well, it’s certainly better to know that something will be array of some things than some thing (which can be array of some things or who knows what else). But let’s say we want to have a method which will check whether user has any badges:

As TypeScript knows that fetchUserBadges method will return Promise<any[]> (a Promise which when it’s resolved will return any[]), it can give us available properties and methods as we’re writing the method:

I know, I know, this is pretty simple example but that’s the whole point – TypeScript on it’s own is not hard. It just takes time to learn how to use it properly, just like it’s the case with any technology out there. Just because you can hack something quickly in the JavaScript doesn’t make it easy. You will still have to learn it’s core concepts in the hard way, by making mistakes and learning from them.

Misconception #3 – TypeScript slows you down too much

There is something people don’t quite understand when they compare dynamic typed languages with static / strong typed ones. If you ever followed any programming memes page (please don’t if you care about your health), you have probably noticed some image with comparison of Hello world program in Java (C#, C++ or any other static typed language) and in the Python. People who make images like this would like to prove to us how superior Python is. Sadly, they just ruin Python’s image with such lack of understanding some basic things.

Obviously, writing down types does make you slower than not writing them. But that initial work will make you faster in the long run. This means that:

Debugging will be easier once your project grows
Navigating code base will be quicker
You will catch many bugs before the runtime
Your code will basically document itself (but this doesn’t mean you don’t have to write documentation)

Now, of course, this doesn’t mean you should use TypeScript for every project. Recently I built a simple weather application in TypeScript (I used TypeScript on both, front-end and the back-end) and I wished I did it in JavaScript. But it’s because I only had three routes and three different views on the front-end. TypeScript didn’t help me much there. This is not a fault of TypeScript. It would have many benefits if I chose to extend my application with various services. And /or more complex state management on the front-end.

Misconception #4 – TypeScript was made by Microsoft, therefore it can’t be good

Many of us probably know about Microsoft’s dark history. But as someone who hated Microsoft with passion (and still don’t have any sympathies towards it), I can say that Microsoft really changed since Satya Nadella took the position of the CEO, at least with their stance towards open source software. If I can list three great things that Microsoft gave us they would be these ones (in no particular order):

C# – modern language with great support for building safe and robust desktop, server-side and even mobile applications
Visual Studio Code – probably the best open source code editor on the market today with hundreds of thousands extensions and constant improvements in each version (built with TypeScript)
TypeScript – do I need to say more?

Saying that TypeScript is bad because it was made by Microsoft is childish at best. We may not like Microsoft’s business strategy but we need to remember that there are thousand of workers in the Microsoft who do their best to build amazing products and TypeScript is definitely one of them.

Misconception #5 – TypeScript is hard to read

Another variation of the misconception #2. When people say that TypeScript is hard to read, they often mean that projects they’re trying to contribute to or libraries they’re using are hard to read. This is understandable, considering how complex types can become in a TypeScript codebase.

If you ever wondered how front-end developers are becoming back-end developers (example from the VS Code codebase)

But guess what? TypeScript is not harder to read than any other strong typed language. It’s about inherent complexity of the project you’re trying to dive in and if you ever worked on production-level apps you know they can grow very quickly. Even in smaller applications type definitions could be long and tedious to read. I remember when I wanted to add types to the Object.entries method. I ended up writing something like this:

export const typedObjectEntries = Object.entries as (
    o: T,
) => Array<[Extract<keyof T, string>, T[keyof T]]>;

And I ended up calling it whenever I was using Object.entries in the project (and this was before I knew I should import es2017). I know what it does, it’s well named and there is no reason to make it simpler just because someone will spend a bit more time reading it. If it’s not so obvious what the method does, you can always add documentation for it. Writing unreadable code is bad, but simplifying code where you shouldn’t could be much worse. Einstein has famously said:

Everything should be made as simple as possible, but not simpler than that.

So, when the code looks hard to read, ask yourself a question. Is it possible for me to simplify this without affecting it's intent? Would simplifying this code bring any benefits or it can lead to bigger confusion? Don't think about problems like these through the prism of the programming language. Always try to solve a problem by applying general solutions, and later customize it to follow idioms of the language.

Conclusion

As it's often the case, this article sums up my experiences of working with TypeScript and in no way tries to pose as a list of empirical facts. I hope it will at least help some people to reconsider their decision to reject using TypeScript in their workflow. Some will disagree with the opinions I expressed here for sure. And that's okay. I may be biased as an advocate of static typed languages, but I would really like to hear your opinions. I also hope this won't cause another heated debate. The goal of this article is to question the most common misconceptions about TypeScript, not to bash JavaScript (which, at the end, TypeScript is mostly).

[1] This doesn't mean you can't find jobs for Haskell or Prolog developers. I think Scheme is used pretty much only on the university, but Clojure is a variant of Lisp which is used more for commercial projects.

5 mistakes I have made as a beginner

Nikola Stojaković — Sun, 09 Feb 2020 15:15:02 +0000

This article was originally published here.

I'll spare you a lecture about mistakes. I know you're here to read a concrete advice. After about four years of professional career and eight years since I wrote the first program, the time has finally come. I'm posting this in a hope you won't repeat the same mistakes I did. But don't expect to dodge all the bullets. In both, life and software development, the best you can do is to minimize the eventual damage.

1. Learning many languages

The first real program I wrote (and by real I don't mean Hello world) was a quiz game in C++. Not long after that I have tried VB.NET, Java, C, Python, C#, Ruby, JavaScript, Perl and even Pascal. I was switching languages like an expert in the industry with decades of experience, while in fact I wasn't even a strong junior. Thankfully, this period didn't last long. But I know there are still juniors doing it today. Dozens of times I would get a question on Quora in this form;

I have learned A and B language, should I learn C, D or E programming language?

Ironically, all these languages exist (imagine there were mainstream languages instead of letters). While it's true that experienced software engineers do know multiple languages, you should start by learning only one language. When you finish learning fundamentals of the language, you should start doing practical projects in it. Same applies to any tool / library / framework.

On the other hand, it doesn't mean you should spend whole your career knowing only one language. Reading about other languages and even playing with them from time to time will help you to broaden your horizons. You will discover new paradigms and new approaches for solving problems. Just don't become too obsessed with it like I was in the beginning of my career.

2. Focusing too much on the theory

The most common thing presented as a disadvantage of self-taught developers is a lack of formal education. For someone who is self-taught, I had good theoretical foundation quite early in my career. But it took few years before I filled my CV with projects I can show off to future employers. Not because I wasn't able to do the same thing in one year, but because I was losing focus on other things.

Now, don't take this wrong. Theory is important. There is a good reason why almost all people who are pushing boundaries of our field have computer science degrees and PhDs. At the end of the day, someone has to build the tools we're using on our job, from compilers to web browsers. But all the theory on this world won't help you to write a better code if you don't start writing it now.

Sure, writing top-down insertion algorithm for red-black trees from the top of your head is great, but does it really serve any purpose for a web developer working on small business sites? I highly doubt that. Try to enjoy the first year of your career as a developer as much as you can and build the stuff without caring whether your queries are highly tuned or whether your classes expose too much information. You will have enough time to worry about that later on in your career.

3. Avoiding to read other people's code

For a long time I had some sort of fear of reading other people's code. I was like, how can I understand something someone wrote X months or years before? Heck, sometimes I don't even understand my own code after a few months! Of course, I knew about comments, but I had no idea about documentation at that time (you should see the look on my face when I discovered there is a way to test your software automatically).

I finally became comfortable reading other people's code when I stumbled upon few problems which required from me to go beyond the library documentation. I had to truly understand what's happening under the surface. And for that, you need to dive in the source code. You need to step through each instruction and ask yourself questions in the process. You can't become a great poet without reading any poetry. And you can't become a great developer without reading any code.

This was an enlightening experience to say the least. It was the moment I realized there are no perfect developers. I have discovered chunks of dead code, unnecessary abstractions, obscure optimizations and lots of shitty code overall. Early in my career I thought that each of my projects will be an empty sheet. What they often don't tell you about software development is that you'll spend most of your time working on the code your colleagues have written. Learn to accept that and your life will be a lot easier.

4. Starting to learn with advanced projects

Compilers, operating systems, browser engines, databases, frameworks, CVSs... There are all sorts of fascinating things people have built in our field. Some of them have multiple human-life spans of work behind them and knowledge passed on by generations. I think pretty much every developer once in their career thought about making their own framework or programming language. Unfortunately, I spent too much time thinking about it and even trying to replicate some of this stuff.

Before you try to run, you should learn how to walk. It's not that you won't learn much from writing your own operating system, for example. You definitely will. But before you try to bite more than you can chew, do a research and see if you have prerequisites to even start doing something. Developing an operating system requires solid knowledge in dozens of topics. Computer architecture, Assembly, file systems, memory management, concurrency etc. And you still won't be able to write something even close to Windows.

Healthy advancement is the key. Moving some parts of your monolithic apps to isolated services can be example of that. Or writing a simple MVC application from the ground up in PHP, without using any framework. This way you won't become overwhelmed by the learning material and you will still learn more advanced stuff.

5. Not spending time with other developers

The first developer I have ever met was a friend from secondary school (I was 16 at the time). Before that I had no idea how important networking is. I discovered there are a few guys from my school who were also developing stuff in their spare time. That's how my professional career started. I did enough jobs to fill my CV with something valuable and landed my first full-time job in 2018. If it wasn't for this connections, my career would probably start much later.

People typically have this notion of developers being lone wolves avoiding any human contact. This has to stop. It's a toxic view which just harms the community. You should ask the questions. You should attend that meetup. One of the reasons why I started blogging was to make new contacts. But it doesn't have to be blogging. You may find public speaking more engaging. Or it could be that you're introverted and feel more comfortable speaking with people online. Everything is fine, as long as you don't lose the contact with the rest of community.

You don't have to spend time with other developers only when you need some help. Being active in the community allows you to keep up on the new trends too. You can explore new approaches for solving problems or even help someone else. One day on my job I struggled to design a layout for the cross-sell popup on one site. I asked colleague who worked as a front-end developer for help. He then introduced me to Flexbox and even gave me Flexbox Cheatsheet. This is one of the advantages of working on-site; you can easily ask for help.

P.S. Don't hesitate to share your own mistakes in the comments.

Mental gymnastics with C# – Part I

Nikola Stojaković — Sun, 02 Feb 2020 22:01:33 +0000

What's the better way to spend a part of the beautiful day than to do some code challenges? Long ago I saw the Daily Challenge series on dev.to where it's staff would post a new problem each day. As I'm progressing with my transition towards .NET ecosystem, I thought this would be the great chance to polish my C# skills.

Instead of just throwing solutions for the challenges, I will go through the mental flow for each problem and explain why I wrote what I wrote. In my opinion this is the most important thing behind solving code challenges. It will hopefully be helpful to those who are also solving them. I will also write unit tests for each solution.

The code probably won't be the most idiomatic C# nor it would be the most performant (even though I will try my best). I truly recommend you to try to solve each challenge on your own first. There is no better way to push limits of your knowledge than to tackle with challenging problems on your own.

Without further ado, let's get started with the actual challenges, shall we? As you will see, the first part will pretty much be the warm-up.

Challenge #1 - String Peeler

Your goal is to create a function that removes the first and last letters of a string. Strings with two characters or less are considered invalid. You can choose to have your function return null or simply ignore.

There is no much going on here. If the text has less than three characters, we will return null. In case it doesn't, we will ensure that our text won't have surrounding white space characters with String.Trim and use String.Substring to leave only the characters we want.

Challenge #2 - String Diamond

The shape that the print method will return should resemble a diamond. A number provided as input will represent the number of asterisks printed on the middle line. The line above and below will be centered and will have two less asterisks than the middle line. This reduction will continue for each line until a line with a single asterisk is printed at the top and bottom of the figure.
Return null if input is an even number or a negative number.

When I stumble upon a problem which initially seems a bit trickier, I like to observe a sample output and see if I can find any patterns. Sometimes, this may be misleading because not all solutions follow the same patterns. But sometimes, it could be helpful, like you will see in this case.

Observing string diamonds, we can see that they contain only spaces and stars. What I tried to do first is to find some ratio between number of spaces and number of stars on the same line. As you can see for yourself, number of spaces is always even, and number of stars is always odd.

      *           8 spaces, 1 star
     ***          6 spaces, 3 stars
    *****         4 spaces, 5 stars
   *******        2 spaces, 7 stars
  *********       0 spaces, 9 stars
   *******        2 spaces, 7 stars
    *****         4 spaces, 5 stars
     ***          6 spaces, 3 stars
      *           8 spaces, 1 star

Take a look at numbers - you see how they repeat in a different order once you pass the horizontal center line of the diamond? This is very important because it will allow us to find how many spaces each line has.

for (int i = startingPoint; i >= -startingPoint; i--)
{
    int spacesOnTheLeftSide = Math.Abs(i);
    int spacesOnTheRightSide = Math.Abs(i);
}

As we can't just move towards zero and move back upwards without changing value of the iterator in the loop itself, we will move past zero and use Math.Abs to preserve positive numbers. It doesn't make much sense to know only the total number of spaces; we need number of spaces on left side and number of spaces on the right side of the line.

You probably wonder where did startingPoint suddenly came from. That's just a placeholder - we will calculate this value right now. In the example above, startingPoint will be four, because we have four spaces on the each side. Four is also a number of rows below and above horizontal center line. We will get this number by dividing width of the diamond (which in this case is nine).

for (int i = width / 2; i >= -(width / 2); i--)
{
    int spacesOnTheLeftSide = Math.Abs(i);
    int spacesOnTheRightSide = Math.Abs(i);
    int numberOfStars = width - Math.Abs(i * 2);
}

Great! Now we have all the numbers we need to actually draw the string diamond. But how are we going to do that without adding new for loops for drawing multiple spaces and stars? We will use the particular System.String constructor overload which will allow us to repeat a character multiple times.

for (int i = width / 2; i >= -(width / 2); i--)
{
    string spaces = new String(' ', Math.Abs(i));
    string stars = new String('*', width - Math.Abs(i * 2));
}

Now we're able to write the whole solution:

Challenge #3 - Vowel Counter

Write a function that returns the number (count) of vowels in a given string. Letters considered as vowels are: a, i, e, o, and u. The function should be able to take all types of characters as input, including lower case letters, upper case letters, symbols, and numbers.

The most obvious solution for this challenge would be to have a counter, loop through each character of the given string and increment the counter if character is a vowel. Thankfully, C# has a killer feature called LINQ (Language Integrated Query), which will make solution even simpler. I'll present solution to you first and then we'll discuss what it actually does.

First, we use String.ToLower to convert whole string to lowercase letters. After that, we filter out consonants by using Enumerable.Where method - we provide the array of vowels and check if it contains the current character. When filtering is finished, we use Enumerable.Count method to get the number of results.

Challenge #4 - Checkbox Balancing

You are given a small checkbook to balance that is given to you as a string. Sometimes, this checkbook will be cluttered by non-alphanumeric characters.

The first line shows the original balance. Each other (not blank) line gives information: check number, category, and check amount.

You need to clean the lines first, keeping only letters, digits, dots, and spaces. Next, return the report as a string. On each line of the report, you have to add the new balance. In the last two lines, return the total expenses and average expense. Round your results to two decimal places.

Example Checkbook

1000.00
125 Market 125.45
126 Hardware 34.95
127 Video 7.45
128 Book 14.32
129 Gasoline 16.10

Example Solution

Original_Balance: 1000.00
125 Market 125.45 Balance 874.55
126 Hardware 34.95 Balance 839.60
127 Video 7.45 Balance 832.15
128 Book 14.32 Balance 817.83
129 Gasoline 16.10 Balance 801.73
Total expense 198.27
Average expense 39.65

Challenge Checkbook

1233.00
125 Hardware;! 24.8?;
123 Flowers 93.5
127 Meat 120.90
120 Picture 34.00
124 Gasoline 11.00
123 Photos;! 71.4?;
122 Picture 93.5
132 Tires;! 19.00,?;
129 Stamps 13.6
129 Fruits{} 17.6
129 Market;! 128.00?;
121 Gasoline;! 13.6?;

This was somewhat boring challenge because I spent more time thinking about structure of the code than the problem itself. Anyway, here is the list of things we need to do here:

Clean the whole text, leaving only letters, numbers, spaces, dots and new lines.
Take the line and try to parse it to double. It should succeed on the first try because the first line should have only the current balance.
If the previous step didn't succeed, try to parse the line and take the check number, the category and the expense.
Form a new line with the data we gathered and add it to the string we're gonna return at the end of the method and save the expense for later calculations.
If there are no expenses it means our checkbox had no data (or at least not valid data).
Calculate total and average expense and add them to the string which is returned at the end of the method.

Let's write a method for cleaning up the text first. We'll use regular expression to keep only allowed characters (I'm pretty sure there is a shorter way to write this).

public static string CleanUpCheckbox(string checkbox)
{
    var regex = new Regex(@"^[A-Za-z0-9. \n]$");
    return new String(checkbox.Where(c => regex.IsMatch(c.ToString())).ToArray());
}

Next, we will have to parse each checkbox line which has a check number, a category and an expense. For this purpose we will use tuples. We need to ensure that each line which violates this format won't break our program, so we'll wrap the parsing process in a try...catch block.

public static (int? CheckNumber, string Category, double? Expense) ParseCheckboxLine(string line)
{
    try
    {
        string[] fields = line.Split(' ');
        int checkNumber = int.Parse(fields[0]);
        string category = fields[1];
        double expense = double.Parse(fields[2]);

        return (CheckNumber: checkNumber, Category: category, Expense: expense);
    }
    catch
    {
        return (CheckNumber: null, Category: null, Expense: null);
    }
}

Finally, we need to ensure that the line we have parsed is valid:

public static bool ValidCheckboxLine((int? CheckNumber, string Category, double? Expense) tuple)
{
    var (CheckNumber, Category, Expense) = tuple;
    return new object[] { CheckNumber, Category, Expense }
                .Where(value => value == null).Count() == 0;
}

Now we have everything we need to write the solution. We will use List<double> to store expenses and Enumerable.Sum and Enumerable.Average to calculate the total expense and the average expense.

Unit tests

Remember I have said that I will write unit tests for each solution? You can find them on my GitHub repository, along with the source code for each solution. Feel free to ask me any question or give your suggestion on solution improvement.

P.S. Since gists were created before the repository, it's possible that some methods / parameters don't have the same name. You can copy code from gists to quickly test the solution, while code in the repository is available in the form of class library.

Organized Rails application with interactors and utilities

Nikola Stojaković — Thu, 02 Jan 2020 19:08:37 +0000

This article was originally published here.

If you have ever used Rails, you know that there is no better thing for quick prototyping. It doesn’t matter how easy is your favorite framework for that. Rails will be dozens of times easier, especially giving the fact it is now a mature solution. That’s the biggest reason why so many startups have used it for building their applications.

I’m not going to talk about Rails today. There are hundreds of articles which have explained it better than I ever could. What I’m going to talk about is the situation when your application becomes complex. If you have used Rails for a long time, you will definitely know what I’m talking about. You just know the feeling when that point comes.

Rubocop yells at you. Your significant other yells at you. Your dog yells at you. Suddenly, the whole world is against you. You’re trying to keep controllers lean but you end up with fat models. Ruby doesn’t seem so shiny anymore. You know where the problem lies, but you don’t know where to start. Beside having cats instead of dogs, I was in exactly the same situation recently.

What happened?

At that time, I was trying to solve the problem of fat controllers by introducing services. Our logic was more complex than in the example illustrated here, but you’ll get the point:

module Services
  class UserService
    extend self

    def create(params)
      User.create!(params)
    end
  end
end

Which would be called in a controller:

class UsersController < BaseController
  def create
    ::Services::UserService.create(params)
  end
end

The problem emerged when services became too general. For example, instead of creating separate services for handling user creation, update and deleting, I have put everything in UserService. I managed to keep my controllers and models lean. But now I ended up with fat services.

Now you may ask why I just didn’t split them? Well, in fact I was thinking about that. Unfortunately, we had some issues shortly after this. They weren’t related to the problem discussed in this article, but they required from us to start from the scratch. Starting from the scratch is generally not recommended (and for the right reason), but in this case it gave us the chance to put things in place.

Interactors and utilities to the rescue

Before we started working on a new version of the application, colleague introduced me to the idea of interactors and utilities. Interactors are basically just an abstraction over some small part of the application’s business logic. Simply said, they’re single purpose objects. If you’re familiar with design patterns, you probably already know it as the Command pattern.

There are few approaches you can use for organizing your code base with interactors. You can use a gem or you can implement them on your own. We chose to do the latter, as our use case was quite simple. Let’s see how it looks on an example of creating a user.

module Users
  module Interactors
    module Create
      module_function

      def call(params)
        ::Users::Utils::Create.call(params)
      end
    end
  end
end

And that’s it. You now have an interactor which calls a utility with the same name. What the heck is utility now and where is all the logic? Well, I lied a bit. Interactor won’t do anything on it’s own. It will rather serve as a middleman between controller and utilities. Together, utilities are going to do the process of creating new user. After all, this process can have many parts – sanitizing parameters, authentication, sending e-mail and so on.

Let’s see how utilities for the interactor above could look like.

module Users
  module Utils
    module Create
      module_function

      def call(params)
        user_params = ::Users::Utils::SanitizeParams.call(params)
        user = User.create!(user_params)

        ::Users::Utils::AuthenticateUser.call(user)
        ::Users::Utils::SendWelcomeEmail.call(user)
      end
    end
  end
end

module Users
  module Utils
    module SanitizeParams
      module_function

      def call(params)
        params.require(:user).permit(
          :username, :password, :email
        )
      end
    end
  end
end

module Users
  module Utils
    module AuthenticateUser
      module_function

      def call(user)
        session[:user_id] = user.id
      end
    end
  end
end

module Users
  module Utils
    module SendWelcomeEmail
      module_function

      def call(user)
        UserMailer.with(user: user).welcome_email.deliver_later
      end
    end
  end
end

In the end, you will just have to call interactor from the controller.

class UsersController < BaseController
  def create
    ::Users::Interactors::Create.call(params)
  end
end

This has multiple advantages:

it will ensure that each part does only one thing
you’ll be able to add more features later easier
it will help you to keep your models and controllers lean
you won’t have to use concerns directories

Okay, where should I put all these files?

Wherever you want, but if you ask me, you should put them in app/lib. This way Rails will automatically require them. Here is the directory structure for the example above:

app/
  lib/
    users/
      interactors/
        create.rb
      utils/
        create.rb
        sanitize_params.rb
        authenticate_user.rb
        send_welcome_email.rb

DEV Community: Nikola Stojaković

Automate boring tasks with scripts in a Node project

Support for TypeScript and path aliases

Iteration protocols in JavaScript

Iterables

Iterators

Infinite iterators

Differences between iterators and iterables

Generators

Conclusion

7 interesting deprecated JavaScript features

Object.prototype.watch and Object.prototype.unwatch methods

with statement

Expression closures

Object.observe and Object.unobserve methods

let expressions and let blocks

HTML wrapper methods on strings

ParallelArray

Conclusion

Why our software is broken?

Personal experience

Alright, but how can I reduce complexity?

Things should be as simple as they can be, but not simpler than that

Conclusion

Frequent questions about programming answered

What kind of equipment do I need to start with programming?

Which programming language should I learn first?

Do I need to be a great mathematician to become a programmer?

Do I need to know X text editor / IDE to become a great programmer?

I just graduated from the university, how can I find a job?

Is Java slow?

Is Java dead?

What’s the best programming language ever?

Is X programming language dead?

Is X programming language bad?

I learned X programming language, what's the next I language I should learn?

What OS should I use for developing apps, Windows, Linux or macOS?

How much hours a day do I need to spend to learn programming?

Why company X doesn’t rewrite it’s application in language Y but stays with language Z?

Linus Torvalds said that C++ is crap, it must be true because he wrote such a big project as Linux, right?

How much time does it take to learn a programming language X?

Do I need to have a degree to get a job as a programmer?

What topics should I study to become a great programmer?

In defense of TypeScript

JavaScript ecosystem has evolved

Misconception #1 - TypeScript has no real purpose

Misconception #2 - TypeScript is hard

Wait a second…

Misconception #3 – TypeScript slows you down too much

Misconception #4 – TypeScript was made by Microsoft, therefore it can’t be good

Misconception #5 – TypeScript is hard to read

Conclusion

5 mistakes I have made as a beginner

1. Learning many languages

2. Focusing too much on the theory

3. Avoiding to read other people's code

4. Starting to learn with advanced projects

5. Not spending time with other developers

Mental gymnastics with C# – Part I

Challenge #1 - String Peeler

Challenge #2 - String Diamond

Challenge #3 - Vowel Counter

Challenge #4 - Checkbox Balancing

Unit tests

Organized Rails application with interactors and utilities

What happened?

Interactors and utilities to the rescue

Okay, where should I put all these files?

Learn more

`Object.prototype.watch` and `Object.prototype.unwatch` methods

`with` statement

`Object.observe` and `Object.unobserve` methods

`let` expressions and `let` blocks

`ParallelArray`