DEV Community: Vaidotas Piekus

Frontend - the red-headed stepchild of product development

Vaidotas Piekus — Sun, 04 Feb 2024 00:09:44 +0000

Producing a digital product is a funny business. Many, many people have to think and strategize, work together, and determine what to build and how to build it, launch, and market the product. It is hard to tell who is the most responsible for a successful product launch. Sales? would not happen without a killer app to sell. Engineering? would not even know what to build or how to market without talented designers/PMs and salespeople. So it is clearly a "it takes a village" type of endeavor, but recognition is not equal.

Recognition is not equal in most aspects of life so why would it be equal in software development? On paper, tech work should be easier to tokenize the amount of work and show ROI on each development cycle. If you work on a piece of functionality like a new checkout component, ideally it should be easy to showcase your part of the work, how it fits in the business goals, and after a while what usage impacts it had. But reality is never that straightforward.

From the perspective of C-Suite in mid-large startups, or even a small startup leadership, this is a rough approximation of how the "importance" pecking order shakes out:

Architecture, data storage, and business logic (backend)
Security and reliability (backend SRE/Security focus)
Design
Frontend
QA
Frontend niches -> Accessibility experts, CSS wizards, UX researchers

It may look unfair if you work in any of the 3-6 categories or have different ideas of what is valuable. But this is how it falls in almost all software product companies. This is not a reflection of how "hard" each field is, for example, frontend niche of accessibility is arguably harder than managing optimal database queries. You can study various accessibility topics for years and adapt the knowledge to multiple quirks of the browsers with never-ending spec changes and anti-patterns of developers. This is hard work and it is a moving target. How many new ways can you optimize MySQL queries each year? Not many, if any.

Frontend devaluation hits close to home as I am mostly focused on frontend work. This has been documented for years by Swyx who has spoken of a silent frontend ceiling. The basic idea is simple -> backend devs will likely never report to frontend devs. Looking at VP of eng roles, directors, and engineering managers, they are almost always filled with people with backend background, nobody comes from design or pure frontend background. This is often reflected in C-Suite company addresses or kudos given, at best you may get a shoutout because you were part of the team that was composed of backend engineers or great designers. I believe that most of the leadership thinks of frontend as a group of engineers who basically take designs in Figma and clumsily remake them in code. If Figma or another tool would have reliable exporting functionality they would take out the middleman -> frontend engineer and let their backend engineers template out the UI.

If you are a frontend engineer, what do you do about this?

There are options. None of them easy, but you have to pivot to either the design side or backend/systems/data side:

Become extremely good at design, UX and work very very closely with PMs/Designers. You may think you are already doing this but you are not, you have to become an advocate of the user, and your understanding of how business works and what brings revenue should be second to only PM. You are so good at executing and understanding what to build that they loop you in every decision and client/stakeholder conversation, you own the user experience and execute at a very high level. Your time of waiting for tickets to drop or Figma designs to be completed is over. This is the only path to positions like Director of Product.
Intentionally move away from frontend focus to backend focus. Going fullstack is okay, temporarily, but learn how the current system works, what database is used and how we are talking to it. Learn everything about authentication and authorization, start contributing to backend in your company. Maybe you are waiting on somebody to build you a route, don't wait, build it yourself and ask for some eyes on it. People are usually happy to see initiative and if you don't completely mess up, you will get ahead. Talk to your manager, and get your frontend work done but start focusing your learning on backend systems and not the latest React canary versions of yet another way to render a <button> on a webpage. This is the path to EM/Director of Eng role.

Is there anything else besides these two options? What if you are passionate about QA, can create CSS masterpieces, or can teach best accessibility practices? If your goal is career progression at a mid to large company I suggest going either the product or backend/security engineering route. If you can monetize your frontend niche and do not care about roles like director/VP - don't worry about it and get even better, there is always a niche to explore and teach. But if you are a generalist frontend engineer, you are on shaky ground.

Plan accordingly.

“Best Practices” as an anti-pattern

Vaidotas Piekus — Sun, 06 Feb 2022 11:59:03 +0000

A Short Story of How Best Practices come to be

Imagine a beautiful green field, full of untapped potential, things to do, systems to build and happy customers to serve. You work alone, maybe with a team, slow or fast but you build a system, an application, maybe it is a website. Along the way you accumulate “dos” and “don’ts”. Perhaps you write it down, share it with the new folks who are joining no longer green but browning field. You are wise and some people call you “senior” or even “staff” something. You write down your ideas and call it Best Practices by Staff or Senior Somebody. That feels nice, you bestowed your hard earned knowledge to the next person, helping and guiding them for months/years to come.

Let’s unpack this a little bit. Okay maybe you did not actually wrote the Best Practices by Staff or Senior Somebody but you were recommended to read it or it was passed down as onboarding document or it came about some other way. In its origin these are a set of rules and ideas written at some point in people’s careers at a particular time in project’s lifecycle. They had some real or perceived value, and got shared across blogs, Twitter threads and internal Slack rooms.

So what is the problem?
The problem is that people take some ideas codified by some team that applied at some point in time to a specific project they were working on. It is very unclear if those suggestions will work out for you and your team. You need to know the context with which those trade-offs were made and what alternatives were considered. You will not know that information, but people will push to make dogmatic choices because they perceive it being a best practice.

DRY

The prime example of best practice that gets too much attention is Don’t Repeat Yourself. Coined by Andy Hunt and Dave Thomas in their seminal programmers bible The Pragmatic Programmer. If you read the linked chapter fully it actually makes a lot of sense. Most people stop reading at what authors call “a tiny and fairly trivial part” - don’t copy-paste lines of code. Duplication is considered a bad way of writing code but they stress that duplication of knowledge and intent is much worse than any other types of duplication. Code duplication is a symptom that rears its ugly head but it is certainly not the only one. If you are changing a single thing but have to make changes in multiple places - that’s bad.

The problem is that people since 1999 (and probably earlier) have been telling other developers to adopt “clean code” practices and “DRY it up”. Without the nuanced context of WHY and HOW this should be done, I find such comments to be about the most useless and lazy dogma out there. By taking this advice to the extreme logical conclusion, code base becomes a completely messy function soup where logic is stretched out into dozens of small files with tiny functions peppered across all of it. Typical day debugging such code involves searching globally for tokens and jumping from definition to implementation in your IDE until it gets dizzy.

What is the problem?

The problem is that people take some ideas codified by some team that applied at some point in time to a specific project they were working on. It is very unclear if those suggestions will work out for you and your team. You need to know the context with which those trade-offs were made and what alternatives were considered. You will not know that information, but people will push to make dogmatic choices because they perceive it being a best practice.

What do we do?

The has been good articles written about revisiting “clean code” and stop recommending it. I’d agree with all of those points raised and add that we should discover our own approaches and, instead of enshrining them into some immutable document, create a culture around mutability when it comes to “best practices”.

let’s encourage new folks to the codebase to be asking questions of why it has been done this way.
let’s rename “best practices” to “a set of ideas we have about the way we communicate in code based on current context” (maybe find a more catchy name).
let’s not be afraid to revisit and change those set of ideas as they should change with the changes to requirements, team size, team seniority levels and tech stack.

Selling Refactoring

Vaidotas Piekus — Wed, 21 Oct 2020 16:11:11 +0000

“Refactoring” is one of those words that are loved by developers and dreaded by project managers. As a developer I love the idea of it, I love initiating, planning and executing a well meaning refactoring. I love making code simpler and easier to understand. So why do we get groans and resistance from PMs and product owners when we bring it up? Don’t they love efficient and clean code practices that lead to a better software product too?

Fundamentally the problem comes from two things: misunderstanding the process and communication of intent.

In order to unpack these concepts we need to briefly remind ourselves what is refactoring.

“A change made to the internal structure of software to make it easier to understand and cheaper to modify without changing its observable behavior.” (M.Fowler, “Refactoring”)

Okay, so the key concepts to highlight is that refactoring does not change observable behavior and that it makes it easier to understand and change the codebase. This sounds straightforward and “good”. Who does not want code that is easy to change and add new features? However selling such idea to the stakeholders, by itself, is a losing battle. The value proposition of “code will be better internally, but with no changes to functionality will be made “ sounds like developers complaining about current codebase and doing work to improve it with no tangible benefits to the clients/stakeholders. It is the classic trope of developers complaining about existing system and wanting to do a total rewrite.

This is where communication breakdown happens most often. Developers trying to sell the idea of large scale refactoring and product owners hearing “a bunch of work for nothing to show for”.

So how do we sell idea of refactoring code in the most effective manner?

We don’t sell it at all, we just do it!

Before the accusations of mutiny let me explain. Refactoring is part of the work we do everyday, it is an integral part of delivering high quality software. Think about it as tending a garden, first we make sure the plot of land where we were asked to plant flowers is ready for it and then we plant flowers. We don’t need to sell the idea of preparing the plot for planting because it is part of the job. In software, we implement tasks by first making sure we understand the context and then adding the functionality. If we find it hard to add a feature or fix a bug, we start the process by making appropriate changes to it is easier to accomplish said task (refactoring).

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

Obviously caveats apply here as they do everywhere, we cant just rewrite the whole system if we find it tricky to add one small feature, we also cant spend all the budget in order to “understand the system”. We need to use our heads and figure out the most effective solution with the time we have. As a general rule, if we think we need a very large scale refactoring (1-2 weeks or more) this is generally full blown software rewrite and not refactoring, as latter consists of small, incremental changes that are done in order to make implementation of feature or a bug fix easier to do.

So next time you are presented with a task to accomplish think and evaluate if context around that task is easy to understand and if you find it hard to accomplish, you may need to be doing a little bit of garden tending in order to make the change easier for you and others who will be finding themselves in that particular plot of land in the future.

Get Faster - VSCode navigation without a mouse

Vaidotas Piekus — Tue, 26 May 2020 14:06:36 +0000

Motivation

Why should you care about mouseless experience when VSCode is a GUI editor tuned to a great mouse experience? The answer is speed.
If you can do make tasks that you do every day but faster it will save you time and keep you in the "flow" longer. It is worth just looking through common default keybindings for VSCode and get a great view of what is possible and what is already available: MAC / Windows

However, the real value proposition is not to try and memorize dozens of keyboard shortcuts but to optimize the "hottest path" for your daily workflow. You want the least friction possible for things you do constantly and that means avoiding mouse/trackpad for most navigation and code editing. Let's dive in.

VSCode Navigation between panels, files, and tooltips

(1) Activity Bar

Depending on the number of extensions and settings your activity bar can look different than mine. All menus in Activity Bar can be reached with keyboard, however, we do not need to work on remembering that obscure extension you maybe use once a month. Let's focus on the most important ones:

File Explorer CMD+SHIFT+E - we use this all the time, navigate between files and explore project file tree structure. One annoyance of default VSCode behavior in File Explorer is when you have file highlighted and hit ENTER it defaults to renaming a file. If you want to open it instead (which is what I want almost 100% of the time) you have to use CMD+Down_Arrow. This is funky but worth remembering.
Project Search CMD+SHIFT+F - extremely helpful to find anything within your project, open it up, enter search string hit ENTER and you are good to go. If you want to jump down to results without a mouse, hit CMD+Down_Arrow and now you can navigate through the files in results.
Source Control CTRL+SHIFT+G. I typically just launch this panel with the keyboard but switch to interacting with the mouse as I like to click through the files, take a look at the changes and commit them right in the panel I find mouse be a little more useful but you can do everything with the keyboard too if you so wish.

Okay, now that we got those down you should never need to break away from your keyboard to launch File Explorer or search within your project!

(2) Navigation between your code, activity bar and terminal

These 3 sections of VSCode are definitely the most used and important for anybody's workflow. I jump around Activity Bar, edit my code and go over to the terminal to restart the server or do any other action all the time. It is very frustrating to keep cycling between these panels with the mouse just to do a quick command.

Focus Left Panel (can be anything from Activity Bar selections) CMD+0
Focus Middle Panel (open files) CMD+1 This technically focuses the first file that you have open, if you have another file opened in the split, you can do CMD+2 and just jump the second file you've got opened.
Show terminal CMD+J or CTRL+`. Notice that this only shows terminal. If we have it already opened and want to focus it, it does not seem that VSCode provides default keybinding for such action. We can define it ourselves. Open Command Palette CMD+SHIFT+P and type "keyboard" and select the one with the JSON "Open Keyboard Shortcuts (JSON)", now we can add any keybinding for any action. Here is what I have: ```

{ "key": "ctrl+l", "command": "workbench.action.terminal.focus" },
{ "key": "ctrl+l", "command": "workbench.action.focusActiveEditorGroup", "when": "terminalFocus" },

You can change that "key" string to whatever feels good, but the objective here is with these two settings you can cycle through editor focus and terminal focus with one keybinding. That is super nice!

**(3) Navigating within a file super fast**
Once you have a file that is opened it is tempting to reach for a mouse and start scrolling up and down the file to find the relevant spot in code or just to gauge the shape of the file. Here are a few key techniques to get you around any file with more efficiency:
  * `CMD+Up_Arrow/Down_Arrow` Jump to the beginning/end of the file. This is very useful when you need to quickly jump to the import section of the file or the export section which is usually at the end.
  * `CMD+SHIFT+O` Navigate between **symbols** within a file. This is the most useful command that nobody uses! It gives you a quick panel to cycle through function definitions/methods defined within a file.
![navigation](https://dev-to-uploads.s3.amazonaws.com/i/e7k17pvybh9f814u90cb.gif)
  * `CMD+F` Find in File. Very powerful and useful command. We all know how to use it but you can actually use this one to quickly jump to a certain section in the file. Say you have function called `adder` you hit `CMD+F` type `add` and with a quick ESC your cursor is already there, ready to edit. Handy!

---
That is it folks! General advice learning these keybindings is to start small, start wherever your "hottest path" is and try and optimize that a little to be more comfortable and faster. Don't try and do too much, memorize all the things, you will struggle to remember it all.

In Part2 of this series, we will be talking about fast code editing!
Let me know below your favorite shortcut and other tips and tricks you discovered.

On Salary Negotiations

Vaidotas Piekus — Thu, 28 Mar 2019 13:02:19 +0000

"Negotiate your salary - ask for more!"

This is one of those mantras that all of us hear all the time, but when push comes to shove, we rarely do it. Doubt besets us, we do not know what to ask or how to ask for it and we start fooling ourselves that company will offer us a fair compensation because "we are awesome and they will see it". We may be awesome, but we still need to market ourselves, work hard at presenting value and fight to get paid fairly.

In fact, as far as choices go, the choice to ask for more or not is one of the most impactful ones you can make in your career. Once you are hired, your salary is likely going to remain the same, with marginal adjustments based on inflation, promotions or bonuses (which are not guaranteed). If you are changing jobs every 2-5 years, the base salary that you sign on, will be the most important metric directly impacting your every day life. Do not waste the chance to significantly improve your situation. Having said that, successful salary negotiation is not as simple as "ask for more and they will give it to you". You need to approach it strategically, purposefully and with preparation. This article attempts to set you on the right path.

Before you start negotiating there are 3 pillars upon which you have to build your case: 1. Understand the market 2. Understand your leverage 3. Apply negotiation tactics.

1. Understand the market

Do your research - The worst thing you can do going into any sort of negotiations is to arrive without doing your homework. You must have a sense of what salary range is reasonable for your experience, qualifications, tech stack and area. Have a number of absolute minimum salary you would need to live comfortably, take into consideration your personal situation and existing commitments (family, parents, kids, pets, etc). You must have a number below which you will not take the offer.

Next step is to find out what other developers in your area with similar experience and qualifications to yours are getting paid. Here are some of the tools you should be using, use all of them and arrive to a range of salary. Just know that no tool is perfect and they all provide a glimpse into reality but not exact numbers, simply approximations. Use these to approximate and balance your expectations.

Your network - this is the most accurate and reliable source of information. If you are part of local tech network you can ask your fellow devs what should be your salary expectations. It is way more likely that you will get an answer to a question "Given that I have 2 year experience developing Full Stack applications in Rails, what do you think would be reasonable to ask for compensation?". You may not get far by asking directly how much other developers are making. Even though sharing salaries could do a lot of good for the community, a lot of people find it uneasy to talk about.
https://www.glassdoor.com/Salaries/index.htm - Salary info is pretty accurate for larger companies and for more junior positions, going higher on the experience ladder, results will wary.
https://hired.com/state-of-salaries-2018 - It has reasonable estimations but only for major city averages, take it with a grain of salt.
https://stackoverflow.com/jobs/salary - it can filter out to your level of experience and area which is neat. They also have a good number of data, even if it is all self-reported.
https://www.payscale.com/research/US/Job=Software_Developer/Salary - can be a decent resource but I find that the range will vary wildly.
https://www.roberthalf.com/salary-guide - This one has a nice report you can access, gives you a good idea of what to expect.

Your objective at this stage is to arrive to a salary range that applies to your situation. Top end will be something of a dream salary while bottom end will be your absolute minimum you would need to even consider accepting the offer.

2. Understand your leverage.

Leverage is very powerful when applied correctly, in a nutshell it is your unique value proposition and the reason why your should be paid more than you are being offered. This is highly personal and entirely dependent on your story and how well you can tell it, here are some of the most common value propositions you can apply:

"Passion" - I personally dislike that word and the connotation it has because it usually means extra work outside of your "normal" job or studies. This can take shape into multiple ways: Blogging, Tweeting helpful content, personal projects, participation in local tech community via meetups, open source contributions, etc. If you are doing some of these activities - great, build on that and advocate for yourself as an active and passionate community member. However, it can be hard to do this if you do not have ample time, maybe you are learning to code on the side, have dependents or demanding life in general. Not everybody can do most of these things but you certainly can blog or share what you are learning once in a while (even if it is once or twice a month).
Previous experience. A lot of us are career changers, going through the path of being self- thought or intensive bootcamp experience. It is likely that you currently have or use to have a non-technical day job. Do not discount that, leverage it to increase your prospects. Worked in a grocery shop? Great! You have good work ethic, handling difficult situations and remaining calm when the storm hits (somebody is yelling at you because they cannot find their favorite yogurt). Think long and hard about transferable skills that you honed in your previous job and that would apply to the tech field. You will be surprised how much will apply.
Current job achievements. If you already have a dev job and are simply moving to another - even better, you are half way there. But your resume should be full of evidence of your personal contributions, value that you brought to the company and projects and how productive you were. This is not a time to be shy and put your team first, this is time to take ownership and showcase that any company would be lucky to have you!
Multiple, competing offers. This one is uncommon and hard to get, but if you are actively interviewing and have a few offers on the table that you are considering, you can share that fact with the company you really want to work for and create leverage that way. Something along the lines of "I would love to make this happen and arrive to the offer that would be agreeable to both of us. If you would consider offering base salary of $XXX instead, it would make it easier to decline other offers I have from X and Y companies at the moment." Work with them on this, do not bluff, do not lie about what you have, ask them how can you work together to arrive at the agreement that is mutually agreeable and reasonable.

3. Negotiating tactics and pitfalls

Being uneasy about negotiations
This stuff comes naturally to almost nobody. You are in a warped asymmetrical power situation, you operate under limited amount of information, you really want this job and the person on the other line has been negotiating as their full time job (if they are recruiter). Having said that, with the research you have done, and the information you have at hand and understanding your leverage you are not hopeless, push past uneasiness and go for it.

What ifs that are in your head:
What if they retract the offer?
That hardly ever happens and if it does, you likely just dodged a bullet. Company that does not respect individuals who know their self worth and are not afraid to ask for it, may not be best environments to thrive.
What if I appear "difficult" and destroy my chances?
You won't. Unless you are being unreasonable and unprofessional, there is nothing wrong about discussing compensation and other benefits.

What if I am [insert your underrepresented minory which which you identify here], I am lucky enough to get an offer!
You got the offer because you are qualified and you convinced company that you would be a productive employee. Your next objective is to convince them that you are worth more then they are offering. Where one falls on privileged/unprivileged scale is irrelevant. Ask for what you think you are worth.

What if [insert anything else]?
The worst that can happen is that they will not budge on compensation question. You may want to give them an out and discuss other perks and benefits instead. Some companies have strict guidelines about base salary, but are okay discussing things like flexible work schedule, vacation days, commuting reimbursement and other perks. If they are not flexible, then that is just that, consider the offer as it stands and make the judgement.

Ultimatums are bad
There is a difference between confidence and reckless demands. Saying "I will not consider anything less than $80k" will hurt you in the long run, if company actually cannot offer that number, you just closed the door to negotiate other benefits and perks that would be part of the whole offer package. As a general rule - avoid using phrases like "I will not", "I do not", "I cannot". Always leave room for conversation and negotiation, always leave an out. On the flip side, if company was actually consider paying you something in the range of $70k-$90k, you just made a mistake that is called anchoring.

Anchoring is a thing
It is often the case that you will be asked very early in your application process the dreadful question - "what is your salary expectations?". It is hard question for two reasons: a) You may not have a good idea b) Your answer will most likely anchor you to the number you say and above which it will be hard or impossible to go. Let's say you answer with $60,000 as your wish right at the begging of conversation with recruiter, you will not be offered more than that at the end (offer stage). And if you ask for more at the that step in the process, you will look rather bad because they are meeting your expectations in the offer letter. You just boxed yourself in.
How to avoid anchoring? You will need to competently and professional deflect the question for as long as seems reasonable. If you are being asked right of the gate by the requiter - deflect it by stating that "I would like to see if this position will be a good fit for me before discussing compensation". Hopefully, by the time you arrive to the last step (final interview and offer) you will have a good idea what you should be asking and that question will not be so doubting.

Final thoughts and further reading

Negotiation is hard and for most people it is neither enjoyable experience or something they are good at. Unfortunately, for the most part in this world, if you want something, you have to ask for it. So do you research, understand your self worth and go into this with the confidence and objective of getting offer that matches your perceived worth.
Here are some further resources that will be helpful:

Building Weather Forecast CLI tool Part 2

Vaidotas Piekus — Fri, 15 Mar 2019 00:34:05 +0000

Building Weather Forecast CLI tool Part 2

This is the second part of the Building CLI tools series that will go into detail how to call DarkSky API from your command line and print out the results and then publish our CLI to npm.

Just to recap from the Part 1 - We will be building something that will look similar to this image:

Part A - Call the API and retrieve info

Let's get the invocation of today's weather forecast from our main entry file

// index.ts
program
  .command("today")
  .alias("t")
  .description("Show weather information for today")
  .action(() => {
    weatherActions.today();
  });

Our weather API logic we will be sitting in a single file - weatherActions.ts where we will be calling DarkSky API, normalizing the data and printing it out. Calling API will be done through axios package and printing it out to the console will be done with chalk, be sure to have those installed before continuing.

//weatherActions.ts
import chalk from "chalk";
import axios from "axios";
const Configstore = require("configstore");
const log = console.log;
const conf = new Configstore("weather-cli");

exports.today = function() {
  const DARKSKY_API = conf.get("DARKSKYAPIKEY");
  let URL = `https://api.darksky.net/forecast/${DARKSKY_API}/38.889102,-77.050637?exclude=minutely`;
  axios.get(URL).then(response => {
    if (response.status !== 200) {
      return new Error(`DarkSky API error ${response.status}`);
    }
    //deconstruct current weather data
    const {
      time: currentTime,
      summary: currentSummary,
      temperature: currentTemperature,
      humidity: currentHumidity
    } = response.data.currently;

    //deconstruct today's weather data
    const {
      summary: dailySummary,
      temperatureHigh: dailyTempHigh,
      temperatureHighTime: dailyTempHighTime,
      temperatureLow: dailyTempLow,
      apparentTemperatureLowTime: dailyTempLowTime
    } = response.data.daily.data[0];
  });
};

OK, let's unpack what is going on in the file above. We are importing previously mentioned dependencies, and API key which we set up in the Part 1.
configstore has a handy method .get to retrieve whichever key you have set previously. We will be using it to call our API endpoint. You will notice that I hardcoded longitude and latitude to my location, we can implement city search as a future goal but for now you can just put your own coordinates instead.

Axios works as normal, after we check that response status is 200 (meaning everything is OK), we proceed to extract relevant data fields from the response payload. We are using object destructuring and rename feature of ES6.

Now if we simply console.log that received information, results will not be great, you may see something like this:

We clearly need to do some time conversion, temperature adjustments to include Celsius and Fahrenheit and basically make it much more appealing.

Part B - Pretty print please

First up - let's make this data presentable.

Temperature needs to be converted to Celsius for convenience to display both C and F.
Humidity needs to be shown in percentage
Time indications need to be shown in human readable form

const currentTemperatureC: string = String(Math.round(((currentTemperature - 32) * 5) / 9));
const dailyTempHighC: string = String(Math.round(((dailyTempHigh - 32) * 5) / 9));
const dailyTempLowC: string = String(Math.round(((dailyTempLow - 32) * 5) / 9));
const currentTimeConverted: string = new Date(currentTime * 1000).toLocaleTimeString();
const humidityPercent: string = String(Math.round(currentHumidity * 100));
const highTime: string = new Date(dailyTempHighTime * 1000).toLocaleTimeString();
const lowTime: string = new Date(dailyTempLowTime * 1000).toLocaleTimeString();

We are doing a few conversions and rounding results with a handy Math.round() method. Time conversions are done with built-in new Date() object. You may notice something strange next to the variable declarations const currentTemperatureC: string = .... Those are TypeScript types. We indicate that the result of that particular assignment should always be a string. It seems trivial at this point, but if we ever want to change our program and how we calculate temperature, this will help us to make sure we do not change the type from string to number for example. You may also be asking why are we forcing some of the numbers to be converted to strings with String() -> that is needed because to print out the results we will be using JavaScript template literals (https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Template_literals) which will make TypeScript yell at us if we try to pass number to a string literal like this:

const someCalculation: number = 14;
console.log(`Print my calculation ${someCalculation}`); //TS yelling at us here!

I am not entirely sure why that is so if you have idea, do let me know in the comment below! 👇

Our last step in this part is to print the results in a nice and presentable fashion. chalk module comes to the rescue!

log(chalk`
|-|  {blue ╦ ╦┌─┐┌─┐┌┬┐┬ ┬┌─┐┬─┐}
|-|  {blue ║║║├┤ ├─┤ │ ├─┤├┤ ├┬┘}
|-|  {blue ╚╩╝└─┘┴ ┴ ┴ ┴ ┴└─┘┴└─}
|-|   🌎 {blue Washington DC, USA} ${currentTimeConverted}            
|-|   🐡 ${currentSummary}                                        
|-|   ☀️ {yellow.bold ${currentTemperature}F}/{blue.bold ${currentTemperatureC}C}                       
|-|   🌊 ${humidityPercent}%                              
|-|   📇 ${dailySummary}                                    
|-|   📈 High: {yellow.bold ${dailyTempHigh}F}/{blue.bold ${dailyTempHighC}C} At: ${highTime} 
|-|   📉 Low : {yellow.bold ${dailyTempLow}F}/{blue.bold ${dailyTempLowC}C} At: ${lowTime}     
`);
return;

Result:

No magic going on here, we are simply injecting our variable values into template literal which we can shape and organize however we like. I added "weather" letters up top and some of the emojis to denote various measurements like temperature, humidity and so on. If it all goes according to the plan, we should be seeing result similar to the image at the top of this post.

Some of the things we could do but is out of scope for this post:

hook up Google API to set any location based on name
implement -week command showing forecast for the week
introduce some tests to make our program more robust

Part C - Publish to NPM

If we want to make this program truly reusable and available for others to install via npm registry, we need to publish it.

For that to happen we need to do a few things to make it "publishable":

Make sure the name is unique or publish under scoped package (meaning that it would go under your username/module-name naming convention).
Add version number to the app. npm uses semantic versioning
Because this project is written in TypeScript, we need to make sure that A) We are not sending over transpiled javascript folder ("lib" folder in our case), add "types" to our package.json and "declaration": true to the tsconfig.json file. Take a look at the required changes below:

//package.json
{
  "name": "@vaidotasp/weather-cli", //-> publishing under our username let's us not worry about unique naming
  "version": "1.0.0", //-> you cannot publish without version number
  "main": "lib/index.js", //-> note that this points to our transpiled .js entry file
  "types": "lib/index.d.ts", //-> that will be generated by TypeScript
  .....
  //other entries are the same as in Part 1
}


//tsconfig.json
{
  "include": ["src/**/*"],
  "exclude": ["node_modules"],
  "compilerOptions": {
    "declaration": true, //-> required step to generate .d.ts file
    "noImplicitAny": true,
    "target": "es5",
    "module": "commonjs",
    "types": ["node"],
    "outDir": "lib",
    "rootDir": "src"
  }
}

Once ready to publish, make sure you have an account with npm, if so, you can go ahead and login through your terminal

npm login

All that's left is to run npm publish --access=public command to push this little program out in the wild and have it accessible to the public.

If all goes well you can navigate to https://www.npmjs.com/package/@username/module-name and find you module!

That is it!

Here is the code if you want to take a look and compare notes. I will still continue to tinker with it so by the time this post is published some of the functionality may have already been changed!

GitHub

NPM

Building Weather Forecast CLI tool Part 1

Vaidotas Piekus — Mon, 11 Mar 2019 13:09:43 +0000

The goal and the setup

Our goal is to build a CLI weather forecast app that shows the local weather information.

Disclaimers:

This will be a step by step guide aimed at beginners that are interested in building CLI tools and learning along the way
There are existing weather CLI tools that are full featured and robust: https://github.com/chubin/wttr.in, https://github.com/genuinetools/weather. This guide does not come close to feature completion, it merely provides an introduction
If you notice any mistakes or have suggestions - let me know in the comments below. I am still learning!

Let's dive in.

Requirements for our app

User is able to invoke weather CLI tool with a single command - "weather-cli"
User is able to set API key via command line (we will be using Darksky API for weather)
User is able to see the following information: time, location, temperature, high temp for the day, low temp for the day, humidity and weather conditions summary

Tools we will be using

Node - it will be running our program
Typescript - No reason in particular except to learn a little bit about Typescript :)
Commander(https://www.npmjs.com/package/commander) - this is a great solution to help us build node based CLI's.

Step A -Program Init

Let's get setup and started.

mkdir cli-weather //let's create a directory to work in
npm init --yes //initialize project and skip the typical questionnaire
---
git init //we want to make sure we can go back when invebitable disaster hits :)

Now that we have empty working directory and billions of NPM packages at our disposal, we can begin with few crucial dependencies

To use typescript for this project we will need:

typescript - we will be writing TS so this one is obvious.
ts-node - typescript executable for Node.js that we will run our files on
@types/node - type definitions for Node.js

npm install --save typescript ts-node
npm install --save-dev @types/node

Next up - create tsconfig.json in your root folder for minimal configuration. That's what TypeScript will be using to inform itself about the intent of our program.

//tsconfig.json
{
  "include": ["src/**/*"],
  "exclude": ["node_modules"],
  "compilerOptions": {
    "noImplicitAny": true,
    "target": "es5",
    "module": "commonjs",
    "types": ["node"],
    "outDir": "lib",
    "rootDir": "src"
  }
}

Noteworthy things about tsconfig file:

"include" points to the directory that will hold our .ts source files, same as the rootDit
"outDir" is where TS compiler will output files that will have the target of "es5".
Setup implies that we will have to have two folders at our root directory, namely "src" and "lib".

Finally, we create our source and output folders

$ mkdir lib src

Step B - index.ts - first lines of code

We need to make sure our setup worked and TS compiler works as instructed. Let's create entry file in our "src" folder.

$ touch src/index.ts

//index.ts content
const sayHello = () => {
  console.log("hey there");
};

sayHello();

Modify the package.json to include the typescript run and compile step. "run" we will use for running our program using ts-node and "build" we will utilize TypeScript compiler to convert .ts files to .js so it can be executed later.

//package.json
"scripts": {
    "start": "ts-node src/index.ts",
    "build": "tsc -p ."
    //-p invokes the project command that compiles based on tsconfig setup,
    //do not forget the "." to indicate the whole directory
  }

Let's test that these two commands work:

    npm run start // should output "hey there"
    npm run build // should not output anything but create index.js file in /lib

If you navigate to /lib/index.js after running "build" this is what you should see:

var sayHello = function() {
  console.log("hey there");
};
sayHello();

Notice that this code is transformed to ES5 version of JS like we indicated in tsconfig.json. Typescript not only adds types to JS but can also make your .ts file that target earlier versions of JS (super handy!)

Step C - Everybody do the shebang

We need to make our program executable, meaning that we can invoke it simply by calling shorthand "weather-cli", without any of that node lib/index.ts nonsense. To do this we need to add what's called shebang at the top of the file- #!/usr/bin/env node which instructs bash to treat the file as an executable in node environment. Next we crack open our package.json file and the bin configuration just like shown below:

// package.json
"bin": {
    "weather-cli": "./lib/index.js"
}

npm will help us out here and create symlink between our index.js file and /usr/local/bin/weather-cli/lib/index.js which will be needed for the npm link command that we will be running next. It creates a link between local package and global folder. Also, if you are running windows, it is very important that you run this as it will help you with correctly setting up the PATH.

npm link

At this point we are all set and in our terminal typing weather-cli should execute the program. We can move on to the actual program logic.

Step D - Set and Get API keys

We will need npm package commander (https://www.npmjs.com/package/commander) to help us with interact with the command line.

npm install commander

Replace contents of src/index.ts with the following code:

// src/index.ts
#!/usr/bin/env node

const program = require("commander");

program
  .version("1.0.0") //arbitrary version - let's go with 1.0.0
  .description("Weather Forecast CLI"); // name of your program goes here

program
  .command("today") //keyword or command to invoke the program feature that goes after "weather-cli"
  .alias("t") //alias or shortening of the command
  .description("Show weather information for today")
  .action(() => {
    console.log("Today is a nice day"); //actual logic that will be executed
  });

program.parse(process.argv); //parses passed arguments to command line

Now if you type weather-cli today (or just t) you should see it print out Today is a nice day. Pretty cool! You can probably see how we can build out feature set of commands from this point on but let's keep going.

To get the weather information we will need an API key from DarkSky. Feel free to use any other free API provider, but I like Darksky because it has accurate information and more than generous free tier.

Once we have this key we need to store it somehow in our program. It is typically kept in environment variables, which would be the best option, but we will be using an npm module configstore which creates a json file in your computer root directory (/Users/username/.config/configstore). I use it because it makes convenient not only to keep API keys but also other config for the tool (like custom settings).

npm install configstore

Here is a basic implementation of commands that will retrieve API key and will set the key. As you will see below we are using Configstore module to access, and store values. You will notice that instead of simple console.log method we are using something called chalk which is a great little tool that helps us with terminal styling. You can find the docs here https://www.npmjs.com/package/chalk but API is a simple one:

//Print out red text in the terminal
console.log(chalk`{red Warning This Text Is Very Red}`);

Main file describing the commands, take a look at "getdarkkey" and "setdarkkey" commands.

// index.ts file
const apiActions = require("./apiActions");

program
  .command("getdarkkey")
  .description("Show Darksky API key if set")
  .action(() => {
    apiActions.getKey("darksky");
  });

program
  .command("setdarkkey")
  .description("Set Darksky API key")
  .action(() => {
    apiActions.setKey("darksky", program.args[0]); //pass the first argument as key
  });

Here is the implementation of those two commands in a separate file. We print the feedback/output using chalk.

//apiActions.ts
const chalk = require("chalk");
const log = console.log;
const Configstore = require("configstore");

//initialize key with null value
const conf = new Configstore("weather-cli", { DARKSKYAPIKEY: null });

exports.setKey = function(key: string) {
  conf.set("DARKSKYAPIKEY", key);

  log(chalk`
    {green DarkSky API Key: ${key}}
  `);
  return;
};

exports.getKey = function() {
  const key = conf.get("DARKSKYAPIKEY");
  if (key === null) {
    log(chalk`
    {yellow Api key for Darksky is not set, use setdarkkey [key] command to set it up.}
  `);
    return;
  }
  console.log(key);
  return;
};

This concludes the Part 1 of the implementation. We've done:

Project setup with core dependencies (TypeScript, Commander, Chalk, Configstore)
Created executable and linked the files so we can invoke weather-cli directly in the terminal
Implemented functionality to get and set API key for DarkSky

So far we have done a lot of prep. All this work will help to build weather forecast logic in Part 2.

Stay tuned!

Learn to code like a pro in 30 days

Vaidotas Piekus — Wed, 23 Jan 2019 14:16:48 +0000

There are no shortcuts. Next time you see an article like this - skip it!

But while I have you fooled, let's talk about patience and deliberate improvement.

Coding, like any other skill, takes time to learn and a lifetime to master. The bad news is that time alone is not going to cut it. If you keep writing for loops for 12 months, you will become really good at writing for loops but not much else. So how do you become a "pro"? You develop a plan.

Plan

Your plan must be designed to stretch your understanding to the very cusp where familiar turns into scary. That is where the learning happens. In the simplest example it goes like this: A) Learn to change the color of a button B) Introduce pseudo-class to make button really pop on hover C) Animate the transitions so it looks amazing

Aim - Incremental addition to complexity building upon base understanding

Avoid - Building the same (in terms of complexity) thing over and over again.

As far as actual plan goes for your goal - there are many to choose from depending on what you are after. First understand your goals, then pick a plan and stick to it.

Patience

So you've got a plan and some time set aside to execute it. Now what?

Keep at it. This is the hardest part, it is inevitable that distraction will creep in. After the first few days or weeks (if you are lucky) doubts, insecurities and distractions will start seeping into your conscience.

What if I drop React and start learning Vue instead? I heard Vue is cool on a podcast.
Maybe I should play with Golang, everybody is talking about it.
Is development even for me? I may be too (dumb, old, marginalized, busy, lazy ⇒ insert your self-sabotage go-to reason here) for it.

These thoughts are very dangerous, I think that is where 90% of good intentions and project ideas and self-improvement goals fail. You have to be pushing through this noise and executing on your plan no matter what. Ignore the distractions and doubts, drown those pesky thoughts with the noise of your fingers hitting the keyboard.

Success will come. But not in 30 days. Be patient.

10 Podcasts for Developers in 2019

Vaidotas Piekus — Fri, 18 Jan 2019 20:28:05 +0000

There are very few good things about having a commute to work every day. Dev podcasts is one of them. You can learn something new, keep up with the latest and greatest and even in some cases be entertained (looking at you Soft Skills Engineering!). Here my list of top 10 podcasts I listen to today in no particular order.*

*I subscribe to way more podcasts than this, but in the spirit of brevity I am cutting the list to 10.

Shoptalk Show

Dave Rupert, Chris Coyier
Front end focused show about design and development of modern websites. Dave and Chris are always worth listening whether they have a guests or not. In fact, their "rapid fire" episodes where they answer questions of their listeners are one of my favorites.

The React Podcast

Chantastic, Michael Jackson
You can probably guess what this show is about. That's right, it is about VueJS (jk). Chantastic and Michael does a great job talking to a wide variety of guests directly or tangentially related to React ecosystem. In fact, they recently did a great episode with React core team about its future. It is a must for those of us who are in React world!

Track Changes

Paul Ford, Rich Ziade
Not strictly speaking development podcasts, however, it is one of my favorites. Paul (of What is Code fame) and Rich are co-founders of Postlight digital product studio in NYC. Their musings about current state of technology, weird rants about social media and ever so interesting guests makes it a delight to listen.

.NET Rocks

Carl Franklin, Richard Campbell
If you are in JS ecosystem, do not be put off by the title of the podcast. It is one of the longest running shows in town, focusing on all sides of technology. It can be a little Microsoft centric in terms of guests but it always delivers high quality content, great conversations and "geekouts" which delve deeply in a topic that expand your horizons. Carl and Richard are pros at what they do and other podcasts have a lot to learn from them.

The Changelog

Adam Stacoviak, Jerod Santo
What makes Changelog special is high production quality and excellent guests. Focusing mostly on Open Source, Adam and Jerod delivers every time. If you want to be in the know of what is going on in the industry I think this is a great way to do so. One of the recent episodes with Dominic Tarr (event-stream incident for those who do not know) was excellent.

Syntax

Scott Tolinski, Wes Bos
This is one of the youngest podcasts in the list. Scott and Wes covers JS ecosystem and latest and greatest technologies, frameworks, libraries, you name it. If you are familiar with their courses, you can expect the same quality work in this podcasts (watch out for those sick sponsor transitions by Scott).

Darknet Diaries

Jack Rhysider
Story driven podcast that dives into the "dark" side of tech. Jack delivers a great insight into data breaches, hacks and other malicious actors and actions of the cyber space. It is a great little gem of a podcast that I discovered fairly recently.

JS Party

Suz Hinton, Kevin Ball, Jerod Santo, Christopher Hiller, Safia Abdalla, others
Second entry from the Changelog family. JS Party is JS centric (duh!) podcast covering a lot of new and more mature technology. Show hosts are great and provide a good variety of opinions.

Front End Happy Hour

Ryan Burgess, Stacy London, Jem Young, Augustus Yuan
While Front End is in the name, hosts cover a lot more topics than that. There is a good balance of opinions and excellent guests. You get the feeling that hosts do come with a lot of experience in the industry and valuable insights.

Soft Skills Engineering

Dave Smith, Jamison Dance
This podcast is a delight, especially when jokes do not land that well, it still makes you giggle. Dave and Jamison focus on other aspects of development (salary negations, navigating company culture, dealing with coworkers and bosses, etc). Write-in questions give you an insight into how other companies operate and what other developers have troubles with.

That is it folks! There are many more, but if you are new to podcasting, these are great to start with!
Share your favorites below!

Resistance and Learning To Code

Vaidotas Piekus — Sun, 16 Dec 2018 16:27:33 +0000

What is Resistance?

Do you know the feeling of sitting down to write code and ending up on YouTube/Twitter/Egghead/Pluralsight watching tutorials and "learning", feeling productive but not actually writing any new code? Some people call it Tutorial Hell, some say it is simply procrastination.

There is another word for it - Resistance.

Steven Pressfield in his book The War of Art describes resistance as something that is self-generated, self-perpetuated, a feeling, a pull that a person experiences when they visualize who they are (a writer, a painter, an entrepreneur) but they do not take the steps to achieve that vision.

In the first passages he describes it well: "Are you a writer who doesn't write, a painter who doesn't paint, an entrepreneur who never starts a venture? Then you know what Resistance is." Adjusting this to the topic at hand - "Are you a programmer who does not program?"

Recognizing the pull of Resistance

As a person who is switching between careers, from known to unknown, from something I am competent in to something that is frightening, I feel the pull of Resistance every day as I sit down to write a line of code. You might too.

If your time is being hijacked by the gravitational pull towards Twitter with the self justification that you will actually learn something while scrolling through the infinite expanses of self actualization - that is a sign.
If you are constantly distracted by new and shiny technologies and have dozens of half baked personal projects that never see the light of day - that is another sign.
If you are constantly googling developer salaries and trying to figure out if the career switch is worth it and is a smart move - well, you are basically me.

Writing this post is, in some sense, Resistance telling me to do this instead of my work. You reading this post is the same. It aligns with our internal fear, fear of success, fear of hard work, fear of pursuing what we were meant to pursue.

Conquering Resistance

Fighting this force in our heads is something that becomes easier with discipline. However, it does not mean that it will ever go away. Every day we will come up with an excuse of doing something else than work, exploring something that is tangentially related to the craft but not the craft itself. We will find justifications, and damn good ones too.

The one answer I found was the commitment to the craft full-time. Not dabbling in and out, but in our heads making the seal of unbreakable pact with ourselves. Steven Pressfield calls it "turning pro".

We show up to work everyday no matter what. We write code everyday. We focus on the long term gains and not the short term gratification. Putting in the work is what matters, success is a side effect.

Rules for success

Show up to work every day for set time. Do not wander during that time, stay focused and practice the craft.
Ignore what others are telling you about the risk, uncertainty or choices. If you feel alive and immersed in the practice of coding, listen to that voice.
Do not focus on immediate metrics as tweet likes, blog post shares, downloads or job offers. Keep you mind on the work itself and the needed steps to reach your future goal. Success will come later, it is irrelevant while you work.
Finish what you stated and move on to the next objective. Do not look back and second guess yourself.
That's it.