This mindset actively discourages the act of looking up information, which is essential for learning.

Imagine that you’re a web developer working on a project that requires the implementation of SSO/IdP. A voice inside tells you, “I’m a professional web developer. I’m supposed to know how to do this already.”

You might spend hours trying to figure it out entirely on your own instead of taking advantage of all the help you can get. And this further adds to your feelings of inadequacy or your Impostor Syndrome.

I suspect technologies like Copilot and watsonx Code Assistant will really challenge those who struggle with this. Remember, it doesn’t matter if you had to look it up. If you got it done, you got it done. This isn’t the Olympics where outside help disqualifies you. Looking up things is an integral part of being a programmer.

(I readily acknowledge that these tools are useful but still being developed and their suggestions can still be inaccurate or suboptimal, but I think the point stands.)

Embrace the mindset that “it’s okay not to know everything; get it done” and such tools become playgrounds for learning and being more productive. If you take the “I’m supposed to know” approach you’ll just see them as crutches and miss out on their potential. Always watch out for psychological barriers. They can make or break you.

The post I’m Supposed to Know appeared first on Programming Zen.

In the previous article on front-end vs back-end developers, I covered the existence of front-end and back-end technologies, which in turn have many options to choose from.

Too many options, in fact. How do we go about choosing what to study? And what about all the other stuff web developers tend to know, such as the command line, Git, and other developer tools?

When you are beginning in this field, not only you do not know a wide range of things, you are likely also unaware of what you don’t yet know.

As such, my goal for this section of the guide is to give you a list of things you should get acquainted with, along with some rationale for why you’d opt for those versus other possible choices.

This list of what to study to become a web developer is necessarily incomplete (I don’t even list learning to debug), but fear not! You will pick up other skills and tools organically in the process of studying these key topics.

In the next article in the guide, we’ll discuss how to go about learning those needed elements as well.

What to study for front-end development

As far as the web is concerned, front-end means three main technologies:

• HTML: The structure of your web pages;
• CSS: The styling of your web pages;
• JavaScript: To make your web pages more useful and interactive.

You need to become familiar with all three of these areas if you’re going to have much of a hope of getting job as a web developer.

If you don’t plan to become a front-end developer, you might get away with a superficial knowledge of CSS (and to some extent JavaScript). However, you should still have a fundamental understanding of both.

For CSS, you should become acquainted with both the Flexbox model and Grid layout. While these terms might not mean much to you yet, they will become familiar as soon as you take a course, read a book, or peruse documentation on CSS.

If you plan on becoming a front-end developer, then you need to be quite decent at CSS.

Learn HTML, CSS, and JavaScript regardless of what development role (e.g., front-end, back-end, or full-stack) you may ultimately end up taking on in your career.

In the beginning of your journey, simply focus on these three in their plain/vanilla form. For example, don’t try to go for fancy JavaScript frameworks like React and Vue right out of the gate.

The only frameworks you might want to explore at this stage are CSS ones like Bootstrap and TailwindCSS, and an old school JavaScript library (i.e., jQuery), to see what they have to offer over vanilla CSS and JavaScript.

What they don’t do is introduce a whole host of new and confusing concepts (like React does), which are best tackled once you have a decent mastery of the front-end trifecta (i.e., HTML, CSS, and JavaScript).

What to study for back-end development

After you’ve spent a couple of months grasping the fundamentals of HTML, CSS, and JavaScript, I’d recommend that you start exploring a back-end development language and framework.

You’ll quickly find that front-end alone limits the type of web applications you can build a fair bit. Want to permanently save and retrieve the data the user gave you? You need back-end tools.

Adding back-end development skills will allow you to create much more useful web applications, as well as to better understand the other side of the coin.

This is useful even if you decide to specialize in front-end development because you’ll most likely be working with back-end developers and interacting with their work from your front-end code.

So far there hasn’t been much controversy in this article. Just about everyone can agree that learning HTML, CSS, and JavaScript is a must. Some will fight me on my suggestion of putting off React or Vue until later (or think that looking into jQuery in 2020 is silly), but nothing as of yet has been truly controversial.

Sides are about to be drawn, however, as I proceed to tell you what to study for the back-end side of things. There are countless possible options out there. At least a dozen of which are squarely reasonable choices.

Some of the most worthwhile candidates include:

• Python and Django
• JavaScript and Express.js
• Ruby and Ruby on Rails

If you already know, or have a hunch, that you will focus on front-end development, I recommend using a JavaScript server-side framework like Express.js.

This will further solidify your JavaScript skills and will enable you to build complete web applications (and APIs that your front-end can then consume).

I’m personally not a huge fan of server-side JavaScript (or JavaScript in general), but if you know that you want to become a front-end developer you must become as skilled as you possibly can in JavaScript. It is, hands down, the number one skill that you’ll need to master in this field.

I would skip the JavaScript and Express.js stack if any of the followings apply to you:

• You didn’t particularly enjoy JavaScript while learning it for front-end;
• You are unsure whether front-end development is right for you;
• CSS and JavaScript offended your sensibilities and you are now seeking refuge in back-end development where you’ll be less likely to work with either of these technologies;
• You want to learn something new and a different programming language is likely to make your profile more appealing to employers.

If that’s you, I recommend that you consider Python and its associated framework, Django.

Python is one of the most popular programming languages in the world and it is quite pleasant to work with. Nowadays, it is almost a given that most well-rounded programmers will know Python.

It’s also the ideal language to have at the ready, should you develop an interest in data science and machine learning down the line.

The most popular frameworks to build web applications in for Python are Flask and Django. Ideally, you’ll want to learn both, but to begin with, I would suggest you focus on Django.

Why Django? It’s highly productive which means that you’ll be able to create fancier web applications with less work, which can be quite motivating when you are starting out. It also ships with a lot of sensible conventions that will in turn teach you how to structure and how to think about the architecture of your web application.

Flask is excellent too and likely the better tool if one is focusing on building small apps and APIs. That said, it is best used once you have a better understanding of how web applications work.

What about Ruby and Ruby on Rails? They are also an excellent choice and my favorite among the options listed here. However, Ruby is not quite as popular as Python, and it is mostly used within the scope of web development.

With Python you get a very similar programming language, plus access to all the data science goodies that are not readily available in Ruby.

Should you decide to pick up Ruby and Ruby on Rails down the line, it will be quite easy coming from a Python and Django background.

As you go through this process, regardless of the language and framework you choose, you must become well acquainted with the REST paradigm which will teach you about HTTP requests and responses, HTTP methods, and response codes.

What about databases?

You’ll also need to become acquainted with databases. For the most part, you’ll have to master the fundamentals of:

• MongoDB: A document-based database;
• PostgreSQL: An SQL/relational database.

Mongo is overused. However, it is common and easy enough to learn, so it can certainly be worth picking up. PostgreSQL, on the other hand, is fantastic and an obvious recommendation.

Once you have an SQL foundation in place, you can switch with relative ease to other relational databases, should a project or employer require it.

Miscellaneous things

The front-end and back-end stacks outlined above are enough to make you useful and capable of landing your first job in tech.

There are however several other skills which are taken for granted. If you are not too familiar with them, you’ll want to invest some time in learning these areas as well.

• Git and GitHub: to store, edit, keep track of changes, share, and release code.
• Basic Linux shell commands: think ls, cat, echo, source, ps,top, grep, find, curl, etc.
• A code editor: I recommend Visual Studio Code unless you already have a different favorite. Learn how to use it efficiently, including leveraging popular plugins. For example, plugins that enable you to autocomplete your code, linters to ensure that it follows idiomatic style and formatting, and more.
• Regular Expressions: quite complex but also handy both within your code and when searching/transforming text via the command line (or within your code editor).
• Web security: you should be able to prevent common security issues like SQL injection, Cross-Site Scripting (XSS), Cross-Site Request Forgery (CSRF), etc.

I suspect you’ll pick up many of these skills automatically as you study the rest of the stuff mentioned earlier on.

Just make sure to supplement as needed so that you are not entirely unfamiliar with any of the concepts listed here.

More advanced front-end and back-end skills

Once you have all of these skills above under your belt, you might be ready to tackle more advanced areas.

If you decide to become a front-end developer, I suggest looking into:

• Accessibility;
• User Experience (UX) principles;
• SEO (Search Engine Optimization);
• Building responsive web applications (web apps that scale to the user’s device resolution);
• Wireframing with Figma or Adobe XD;
• Styling with Sass;
• Webpack;
• React/Redux or Vue/Vuex.

If you decide to become a back-end or full-stack developer, I’d recommend exploring more in depth:

• Algorithms: learn more about traditional algorithms and data structures concepts often taught in computer science university courses, including the concept of Big O notation.
• SQL, going beyond the language by looking at more advanced features modern relational databases have to offer (triggers, stored procedures, etc).
• Flask (if you opted for Python) or Sinatra (if you opted for Ruby).
• GraphQL: go beyond REST and see what all the buzz is about.
• Deployment and scaling with containers using tools like Docker and Kubernetes.

Note that for all of the technologies I’ve mentioned here, this list is still not an exhaustive one by any means. This is by design, as it really doesn’t need to be all-encompassing. Most professional web developers have not mastered every entry on this list.

So, if you decide to become a front-end developer, mostly ignore the advanced back-end stuff, and focus on the front-end skills.

Conversely, if you decide to become a back-end developer, focus on the advanced back-end skills by studying, practicing, and building projects without worrying too much about the advanced front-end skills side of things.

You just need to become really good at the key components for the role you decide to take, while not being entirely unfamiliar with the rest of the entries on this list.

What’s next?

Now that you know what you should be studying, we need to address how to actually go about studying it.

Do you need a degree to become a web developer? Should you enroll in a development bootcamp? We’ll cover these questions and much more in the next article in this multi-part guide.

Stay tuned and don’t forget to subscribe, if you haven’t done so ready.

The post What to Study to Become a Web Developer appeared first on Programming Zen.

If you want to learn to code so that you can become a web developer, welcome. You’re in the right place.

Before we discuss what kind of web developer positions are available and what the differences between front-end, back-end, full-stack, and DevOps are, I’m going to take the scenic route and start with what coding is.

This is necessary because I make virtually no assumptions about your existing knowledge. If you are an absolute beginner, this is the guide for you.

What is coding?

Coding is the act of writing code to program machines like computers and mobile devices. OK, what is code then? Code is the set of precise instructions we give to said machines to execute the actions we want them to take.

The instructions need to be precise because computers, unlike humans, cannot make a bunch of assumptions on the basis or prior experience.

If I asked you to draw a house, you’d probably start jotting down something reminiscent of what a 5 year old would draw. You’ll start with a box, add a pointy roof, a door, a window, etc. If you are really artistically inclined, you might draw a 3D version that looks nicer. In either case, you will be able to handle my generic, open-ended request and deliver something that satisfies it.

Generally speaking, the computer cannot assume what the house should look like, as you would. How thick should the lines be? What color (if any at all) should be used? How big should the house be? What style? And so on.

In short, a computer didn’t draw houses in kindergarten. Yes, it can draw amazingly intricate houses with fantastic degrees of detail, but you’ll need code that very precisely instructs it to do so.

Consider the calculator application that is installed by default on your computer.

A programmer wrote a bunch of code so that when you click on the Calculator icon, the computer launches the application on your screen, presenting you with a series of numbers and operators to choose from.

As you interact with the application, for example by pressing 6, x, 7 and =, the computer, instructed by the programmer’s code, will know what to do. (Namely, multiplying the two numbers and displaying the result for you.)

What’s the difference between a program and an application?

Some computer programs do not have a visual user interface at all, in which case we do not call them applications.

That’s the main difference between a program and an application. They both require code, but only applications have some kind of visual user interface that the user can interact with.

The user interface (UI) doesn’t have to be a window within your desktop operating system (e.g., Windows or MacOS). It can be on your mobile device or even a web page that you access through a web browser like Chrome or Firefox.

Different types of applications and developers

An application that you access on your desktop computer is called… drum roll… a desktop application. One that you access on your mobile device (e.g., Apple or Android smartphone) is called a mobile application. And one that you access through a web browser? You guessed it, a web application.

It turns out that the type of code we must write to create these different types of applications is somewhat different depending on the type of application we are creating.

Many of the concepts are the same but the programming languages, libraries (essentially, prewritten code), tools, and problems you’ll face as a programmer will be different depending on which platform you are targeting.

This is why professional programmers will often specialize in one or maybe two of these types of application development. So, you can be a desktop developer (less common these days), a mobile developer, or a web developer.

Sometimes, you’ll hear the term “app developer” which is a synonym for a mobile developer, given that “app” is often used to specifically refer to mobile applications.

Some programmers specialize even further, and are just iOS developers or Android developers, depending on the type of mobile devices they target.

Since not all programs are applications, it’s worth noting that there are many other types of developers who don’t work on applications.

For example, those who work on the operating system itself, programs that facilitate networks of computers to communicate, or code that enables hardware components to communicate with each other.

The Web won

There are plenty of viable careers to be had in mobile and other types of development, however since the aim of this guide is to help you become a web developer, we are going to focus on this particular subset of the development landscape.

Twenty-five years ago, the majority of developers were desktop developers (or a specialized version, like a Windows developer).

Over the past two decades, the web exploded in popularity. So it might reassure you to know that today the overwhelming majority of programmers are web developers.

The web is certainly not going anywhere, so the skills you acquire will serve you well for a long time to come.

Static vs dynamic pages

Alright, let’s focus on web applications. What are they and how do they work?

Let’s start with a simple web page, rather than a full-blown web application. When you visit https://antoniocangiano.com, my homepage, you are visiting a very simple static page.

My homepage is a so-called “static page” because it doesn’t dynamically change. For example, it doesn’t pull the data from a database like when you search for a product on Amazon.

It’s just a static document containing some text, images, and links organized in a somewhat logical and pleasing (if minimalist) manner.

When the web first come about in the early 90s, that’s all it was for the most part. A bunch of static pages linking to each other.

When server-side dynamic web pages became common, it transformed the web. We could now, among other things, collect information from the user, store it in a database, and dynamically display to the user content on the basis of their request.

You could even customize the page that was rendered to the user on the basis of who was logged in, for example.

Over time, these capabilities evolved to a point where web applications can deliver rich desktop-like interfaces and user experience.

Technically, this blog you are reading is a web application written in HTML, CSS, JavaScript, and PHP. It allows me to log in as an administrator and write blog posts. It allows you to comment, search for posts, subscribe to my RSS feed, see related content, and much more.

Web applications can be as simple as a plain todo list or as complex as the online version of Microsoft Excel or an elaborate video game.

How does requesting a static page work

When you type https://antoniocangiano.com/ in your browser’s address bar and press enter, the following steps take place:

• A DNS (Domain Name System) server is called to translate the hostname antoniocangiano.com to an IP (Internet Protocol) address where the site is actually hosted. You can think of DNS as white pages for the internet, where instead of people’s names being mapped to their phone numbers, you get website names mapped to their servers’ IP addresses. Knowing the IP address of the server hosting the site will allow your browser to send the request to the right server among the millions of servers available on the internet.
• The request you made tells the server that you want to get the page/information available at /. The server will grab the index.html file for my site and send it back to your browser as a response. (On a static site, / will typically render index.html just like /about would render the content of about.html. This is by convention and not always the case.)
• Within that HTML file, I also reference a CSS file on the server, some images, and a little bit of client-side JavaScript. Your browser will request all of these elements from the server, and ultimately render the HTML page for you to see.

(This is a simplification, but conceptually these are the major steps.)

There is no back-end development going on here. HTML, CSS, and client-side JavaScript are all front-end development technologies.

HTML provides the structure and content of the page. CSS determines the style of the page (font size, spacing, padding, colors, etc.). And JavaScript determines some behaviors of the page as you interact with it.

In the case of my homepage, when you move your mouse over the icons at the top, you’ll see a little tooltip pop up appear. That’s a bit of JavaScript in action.

I clarified that it’s client-side JavaScript because nowadays there is also server-side JavaScript which is indeed in the scope of back-end development. When I say “client-side”, I mean JavaScript that is executed by your browser.

How does requesting a dynamic page work

Web applications are collections of dynamic pages (and sometimes dynamic and static pages). Requesting a dynamic page is conceptually similar to requesting a static page, but behind the scenes there are a few more steps taking place.

For example, let’s say that you enter “iPad” in the search box of this site and press enter. You’ll notice in the address bar that you’ve made a request for https://programmingzen.com/?s=ipad.

There is no ipad.html file on the server, given that you could have typed anything into the search field.

(Ignore caching for the sake of this simplification, if you are already familiar with the concept.)

So behind the scenes, instead of locating the static file and issuing it in response for the browser to render, there are two extra steps:

1. The web server understands that you want posts related to the iPad. So the dynamic page will send a request to a database server that contains all my posts. Using a language called SQL (Structured Query Language), it will ask for a list of posts containing the word “iPad”.
2. With that information available, the web server will execute the code in the dynamic page which will use the list of posts to formulate a response which includes a series of neatly arranged iPad-related posts.

Ultimately, what’s sent to your browser is still a bunch of HTML, CSS, and JavaScript. However, it didn’t come from a file on your server. It was dynamically generated based on information stored in the database.

Imagine for a moment that some posts on my site were available only to subscribers. The code of the dynamic page would need to check whether the person is logged in or not, whether they are a subscriber, and then alter the response accordingly.

If the user is a subscriber, include subscriber-only iPad posts in the list, if they are not, exclude those posts and just return the free ones available to everyone.

As you can imagine, the ability to dynamically generate the response depending on certain conditions is quite powerful and is the basis of how web applications work.

Front-End vs Back-End technologies

In terms of technology, what did we add to the HTML, CSS, and JavaScript front-end stack? We added code to the dynamic pages which can then make calls to a database and generate a customized response. PHP and SQL code in my case.

This code can be written in a variety of programming languages, however. Some popular examples are Python, Ruby, Java, Elixir, and even server-side JavaScript.

We’ll discuss why you’d use one language over another or which to choose to land a job, in the next installment of this guide. For now, know that back-end development will require you to be familiar with a server-side programming language.

You’ll also need to know SQL and be familiar with how databases work.

Truth be told, back-end developers will need to know quite a bit more than just another programming language and databases.

For example, they’ll typically leverage a web framework like Ruby on Rails, Django, Flask, or Express.js to be more productive and write fewer lines of code to implement the features needed by the web application.

So you’ll also need to develop familiarity with whichever framework is most popular for your language of choice.

A lot of front-end developers are not writing plain JavaScript either. They too have to worry about frameworks and libraries, typically for JavaScript (and even CSS). Popular JavaScript options are React, Vue, Angular, and Ember.js.

Front-end developers will also need to worry about accessibility and providing a good user experience (UX) for the end-user. Huge topics that have dedicated specialists in their own right.

We’ll cover what you need to study in the next article of this guide.

Front-End vs Back-End developers

While it is good to have an understanding of both front-end and back-end, most web developers end up specializing in either front-end or back-end.

Historically, front-end development had a certain stigma. It was perceived as easier. These days, I don’t believe this is a valid stance anymore.

The capability of web interfaces has grown dramatically over the years and so did the complexity of technologies leveraged to build such interactive and rich user interfaces.

It’s worth noting that back-end developers’ salaries still tend to be higher than front-end developers’ ones. But this might be at least in part because the majority of beginner web developers start with front-end technologies.

After all, you can’t be a back-end developer without knowing the fundamentals of HTML, CSS, and JavaScript, but you could in theory be a good front-end developer without knowing server-side languages and SQL.

Of course, exposure to both sides of the Web development line is always beneficial.

Full-Stack developer

Full-Stack developers are unicorns born in an enchanted forest located where the Hanson and the Eich rivers meet.

More seriously, it’s rare for someone to be amazing at both front-end and back-end development, but there are plenty of developers who are competent at both.

Larger companies tend to prefer specialized people, because they have the resources to hire larger teams that will include both front-end and back-end developers.

Startups and other smaller businesses might only be able to have one or two developers on hand, and therefore might find a full-stack developer who can build the entire web application to be a more practical option.

DevOps specialists

Writing web applications is only one part of the equation. You then need to deploy them somewhere on the internet so that they’re available to the public. (Pushing code to production, to use common lingo.)

You also need strategies to keep them running smoothly and handle updates and new releases of the code you write.

In smaller operations, this often falls on the web developer’s shoulders. Over the years, however, the role of DevOps engineer became its own profession.

Today, larger organizations will hire DevOps specialists/engineers to work alongside developers and system operators/administrations to ensure the best deployment practices.

As you work on becoming a web developer, you’ll inevitably pick up some of the skills possessed by DevOps. However, you don’t need to become a DevOps expert, unless you discover that it’s what you enjoy the most and decide to pursue that as your career.

Which one should you choose?

It’s way too early for you to commit to becoming a front-end, back-end, or full-stack developer.

The best you can do is learn the fundamentals and then decide on the basis of what you enjoy the most, what comes more naturally to you, and ultimately what you tend to be good at.

Some people might struggle with grokking databases but are capable of creating wonderful user interfaces. Others might be very good at solving algorithmic problems but fail miserably at putting together a user-friendly UI.

You’ll find out where you fit very soon.

What’s next?

In the next article of this How to Become a Web Developer and Get a Job guide, we’ll cover the technology stacks I recommend to maximize your chances of becoming a professional web developer and landing a job.

I’ll also discuss which languages, technologies, and tools you need to study to break into this industry.

That master list can act as a road map of skills you must acquire in the upcoming months to become a web developer.

The post Front-End vs Back-End Developer appeared first on Programming Zen.

I’ll split the guide into a series of articles. Once the guide is complete, I will also make it available for free to my subscribers in PDF, EPUB, and MOBI format.

Who is this guide for

This guide is for anyone who wants to become a Web Developer and get a job as a professional developer.

The “how to become a Web Developer” portion of the guide is going to be specific to web development, but even those seeking to become other types of developers will likely benefit from its insight.

The “how to get a job as a developer” portion is much more generic and will serve you well regardless of your chosen specialization.

I’m writing this guide with two kinds of people in mind. Young people hoping to become professional developers and existing professionals who are hoping to switch careers (or who may be returning to the workforce in the case of stay-at-home parents).

These are the kinds of people I have personally helped in the past and those I have the most experience with. Nevertheless, the advice provided throughout this series should be suitable for anyone whose goal is to land a developer job.

Requirements

I’ll take for granted that you have used a computer before and are somewhat web-savvy. As a litmus test of the sort, I’m assuming you know that Google Chrome and Mozilla Firefox are two browsers and can install an extension/add-on (or could figure it out by Googling it).

I’m also going to assume that you’re smart but not necessarily a genius like I am. That’s a joke, by the way, I’m not a genius. I’m a super genius. 🙂

Jokes aside, the media has created a certain stereotype of what a programmer looks like. The asocial genius wearing a hoodie can be an intimidating benchmark for those starting out.

The truth is developers come in all shapes, sizes, and forms. And although developers are reasonably smart people, being exceptionally gifted is by no means a requirement. You don’t even necessarily need to be good at math.

Technical ability, as we’ll discuss more in-depth soon, is also not the only desirable trait of a great developer. Your communication skills and ability to collaborate are just as, if not more, important.

Who am I

I’m a Software Development Manager and AI Advocate at IBM. I’ve been a professional Web Developer for 20 years.

Within IBM, I’m known as the guy who got the company to adopt Rails and Django, in the early days of these technologies, and more recently I’ve been gradually doing the same for Elixir and Phoenix. (If you don’t know what any of this means, no worries, we’ll cover your options soon.)

Over the years, I’ve provided advice to countless people who were hoping to make it into our industry, many of whom I’ve personally mentored.

For the past twelve years, I’ve been doing the candidate selections for my team. As a result, I must have reviewed thousands of résumés, interviewed hundreds of developers, and hired a few dozen applicants.

I’m also the author of a couple of technical books. One on Rails for Microsoft developers (painfully obsolete at this point) and one on Technical Blogging (current and quite useful to those seeking to advance their career in tech).

Among too many other things, I’m also the author of a popular chatbot course that’s been taken by over 100,000 people worldwide on Cognitive Class (a volunteer initiative for which I’m the marketing manager), Coursera, and edX.

This is not to brag (like many of us, I tend to feel underaccomplished at times), but rather to say there is a method to my madness and that my approach appears to have helped a lot of people. I’m hoping that it will help you as well.

A disclaimer on how to become a Web Developer

“How to become a Web Developer” doesn’t mean that I will teach you how to program in HTML, CSS, JavaScript, etc. I could do that, but this svelte guide would become a 1,200-page tome in no time flat. And it would likely be one that would echo a lot of resources that are already available elsewhere.

Instead, I’m going to tell you what to study, along with how and why to study it. I will also point out various useful books and resources where you can learn more about the technical topics I mention.

I’ll give you the roadmap, but I won’t be doing the actual studying for you. 🙂

This is all very doable though, fear not. There are millions of developers, most of who are not any more special than you are. However, it would be a lie to say that there won’t be a lot of work involved on your part.

It will be, but if you’re not afraid of some elbow grease, a better career (and possibly life) awaits you on the other side of that dedicated effort.

Why would you want to become a developer

Instead of elaborate arguments trying to sell you on the profession, I’m going to list a few quick, bullet points in favor of becoming a Web Developer in the 2020s.

• Web development is future-proof. AI will take over a lot of jobs, but most developer jobs won’t be automated away any time soon.
• Web development can be remote. Most forms of software development, not just web development, can be carried out remotely. So you’re less likely to lose your job if, as if it’s currently the case with COVID–19, you are forced to be inside for extended lengths of time. There are, of course, other variables at play, but this improves your odds of remaining employed.
• Web development is creative. You’ll be able to engage both the analytical side and the more creative parts of your brain.
• Web development is fun. Two aspects that make web development really fun are being able to instantly see the results of your work (right in your web browser) and the ability to share it with the world at large. All this, without them having to install anything on their devices.
• Web development doesn’t require a degree. A degree in Computer Science or Software Engineering is certainly helpful and provides many useful fundamentals. However, it’s by no means required to become a Web Developer or to get a job as a Web Developer.
• Web development pays well. Try getting a job that pays six figures without a degree in most other fields; they’ll laugh as they escort you out of the interview room. Sure, your first web development job is unlikely to pay six figures, but you can still expect a generous salary right out of the gate from many companies (in the US, a junior developer will earn, on average, $66,695 per year).

Those are some of the major perks but, as you’ll find out if you go through this process, the work itself can definitely be its own reward as well.

Of course, your landlord expects dollars not your sense of accomplishment and self-satisfaction. But thankfully, web development covers you there as well.

What to expect next

This first article in our series is primarily an introduction to what is to come in future entries.

Here are some of the topics that I’ll cover next:

• Front-End VS Back-End Developer: Front-End Developer, Back-end Developer, Full-Stack Developer, DevOps: what are the options, and what do they entail?
• What set of web development technologies you should study. The ones that maximize your chances of getting a job as a web developer.
• How to study for your chosen web development stack (including specific books, courses, and resources).
• Résumés, Github, and project portfolios.
• Using social media and blogging to stand out from the crowd and attract job offers.
• Finding the right jobs and applying for them.
• Mastering the interview process.

For now, remember that you can do this. Together we can get you in shipshape for your future web development job.

And please don’t forget to subscribe below to ensure you receive the next installments of this guide.

The post How to Become a Web Developer and Get a Job With No Experience (Guide) appeared first on Programming Zen.

In the following example, we take a list of integers and pass it to the Enum.uniq/1 function which removes duplicates from the list without altering the original order of the remaining elements.

list = [1, 2, 2, 3, 3, 1, 2, 4]
Enum.uniq(list) # Returns [1, 2, 3, 4]

If you are trying to only remove consecutive duplicate elements, then there is Enum.dedup/1:

list = [1, 2, 2, 3, 3, 1, 2, 4]
Enum.dedup(list) # Returns [1, 2, 3, 1, 2, 4]

(Note: We append /1 simply as a notation indicating the arity of a function, that is how many arguments it accepts. my_func/1 accepts one argument, my_func/2 two, and so on.)

Enum is full of helpful functions when working with collection data types that implement the Enumerable protocol (e.g., lists, maps, ranges, streams, etc.) and it’s worth getting acquainted with.

Removing duplicates using recursion

Alright, Elixir does the heavy lifting for us in this case, but how would we go about removing duplicates from a list in Elixir without using Enum.uniq/1? I mean from scratch, simply using recursion without relying on Enum, sets, :lists.usort/1, etc.

It is worth asking such a question to both exercise our recursion muscle (something that doesn’t come naturally to most programmers) and so that we’re ready to handle conceptually similar problems that do not have pre-made functions but could benefit from a recursive solution.

There are likely a few ways to implement this, but this what sprang to mind when I thought about it:

defmodule MyList do
  def uniq([]), do: []

  def uniq([head | tail]) do
    [head | for(x <- uniq(tail), x != head, do: x)]
  end
end

Calling MyList.uniq(list) will then return the same list without duplicates as Enum.uniq(list)did. (Although, it’s worth noting, that we implemented a List-specific version of the uniq/1 function).

Let’s see how this works. If the list is empty (i.e., []) we obviously return an empty list, as there is nothing to remove. This is our base case for the recursion.

If the list is not empty, it will have a head and a tail, and we use Elixir’s pattern matching to bind the first element of the list passed to the function to head and the rest of the elements to the list tail.

Note that a proper list with a single element will simply have an empty list as its tail. So writing [3] is equivalent to writing [3|[]] where 3 is the head, [] is the tail, and | is the cons operator (short for constructor operator, as it’s used to construct lists).

So far so good. Here is where things get a little trickier. Let’s analyze this line:

    [head | for(x <- uniq(tail), x != head, do: x)]

The code is wrapped in square brackets [...]which means that we are returning a list. Then you’ll notice the | cons operator. So we are constructing a list that has head as its first element and whatever the rest of that line of code does, as its tail.

This makes sense if you think about it. Sure, the list might have duplicates, but the first element will always be included. If a duplicate of the first element exists, that’s the one that is going to be removed and not the first element.

So we are building a list and the first element of the original list is also the first element of our deduplicated list. What goes into the rest of the list?

Comprehensions

We see a for. Unlike many programming languages, for is not a loop keyword in Elixir. Rather, it is used for comprehensions (a form of syntax sugar to generate lists from existing collections). Syntax, which is not too different from mathematical notation.

Here is a simple example of how to use them:

for x <- [1, 2, 3, 4], do: x + x # Returns [2, 4, 6, 8]

“For each element x in [1, 2, 3, 4] do x + x and put the result in a list.”

It also accepts filters, which allows us to specify a condition:

for x <- [1, 2, 3, 4], x < 3, do: x + x # Returns [2, 4]

In this example, the condition is that x is smaller than 3, so only the first two elements, which are lesser than 3, get doubled and added to the resulting list.

Recursing our way to the base case

OK, back to our “cryptic” line:

    [head | for(x <- uniq(tail), x != head, do: x)]

head is our first element and then we are using a comprehension to generate a list without duplicates.

We are saying, for each x in a deduplicated tail, add x to the list if it’s different from our first element head.

The part that gets people weirded out about is recursively calling uniq(tail). We can get away with this because we have a base case that ensures we don’t recurse forever.

At each call of uniq(tail) we are making the tail shorter by one element.

For example, executing MyList.uniq([1, 2, 3, 3]) will make the following recursive calls:

• MyList.uniq([1, 2, 3, 3])
• MyList.uniq([2, 3, 3])
• MyList.uniq([3, 3])
• MyList.uniq([3])
• MyList.uniq([])

When we eventually get to the tail being [], which is our base case,[] is returned and MyList.uniq/1 is no longer called.

Recursion can be hard to grasp at first, but it’s a powerful tool and a staple of functional programming, so it’s well worth practicing.

As pointed out in the comment section, this implementation is quite illustrative but not very efficient. In production, you’d want to opt for the built-in functions or implement a tail-recursive version that leverages MapSet. And although tail recursion is faster in this case, it’s worth noting that even that is not a silver bullet.

The post Removing Duplicates From a List in Elixir appeared first on Programming Zen.

You’ll need to edit your config/dev.exs configuration file to change the host key as follows:

http: [port: System.get_env("PORT", "4000")],

System.get_env("PORT", "4000") retrieves the value of the PORT environment variable if one has been set. If the environment doesn’t have the specified variable (i.e., PORT), it will default to 4000.

You can then boot your Phoenix server by passing the variable value to the command as follows:

$ PORT=5000 mix phx.server

This will run the server on the port you specified, in this example 5000.

The name of the environment variable is arbitrary. We used PORT but we could have opted for PHX_PORT or something else altogether. Just so long as your configuration file and environment use the same name.

You can, of course, set the environment variable outside of the mix phx.server command, for example in your shell profile.

The post Specify a Port when Booting a Phoenix Application appeared first on Programming Zen.

I can appreciate the usefulness of Python, the simplicity of Go, and the mind-expanding nature of Haskell. Yet, anything that isn’t Ruby felt like a usability downgrade. It’s all highly subjective, ça va sans dire, but Ruby was always my favorite.

It’s not every day that a language comes along and genuinely excites me to the point of putting Ruby aside (within the scope of what it’s great at doing).

I <3 Elixir

That language is Elixir. I’ve been using it on and off for a few years now. I first talked about it back in 2016 and even managed to convince my team at IBM to adopt it to an extent. It’s working out well for us so far and I have a hunch we might double down on it soon.

Since I have a little more time, due to being stuck inside, I’ve been on a “study anything in sight related to Elixir and Phoenix” kick lately.

I am a big fan of Mike and Nicole Clark of The Pragmatic Studio and in the past have highly recommended their Ruby and Rails courses. So I decided to start taking their Elixir courses as well. In this post, I’ll give you a fairly detailed review of their largest course on the subject, Developing with Elixir/OTP.

Who is it for?

Developing with Elixir/OTP is aimed at programmers. It’s so well explained that beginners can give it a shot, however, they are not the target audience.

The course assumes you have zero knowledge of Elixir itself but it’s not going to explain basic programming concepts when they are not novel or unique to Elixir.

Experience with Ruby is not required nor assumed, but it’s beneficial. This isn’t so much due to the way the course is presented (though there are a couple of nods to Ruby programmers). Rather, it’s the similarity (on the surface) between the two languages.

How much time do you need to invest?

Developing with Elixir/OTP is a 6.5 hour course divided across 30 modules. There is no way for you to take this course in 6.5 hours and get anything worthwhile from it.

In fact, the secret sauce is that each module has a Notes section dedicated to expanding on the topic, providing tips and tricks, as well as exercises. 

I would estimate that it took me around 20 hours or so to finish, despite being very familiar with the subject matter. Mind you, I do like to experiment quite a bit within IEx to veer off the beaten path.

Estimate 30 hours of your time, an hour per module, if you intend to fully absorb and experiment with the material presented.

Unlike their Rails course, you won’t develop two applications (one while watching the videos and one in the Notes section). In this course, there is only one application that is mostly developed in the videos and then enhanced in the Notes through exercises.

This will save you a lot of time at the small expense of having to pause and resume the video to type along.

Another time-saver is that the code for each module in the course is provided so that you’re never lost. Particularly useful to copy and paste the more tedious parts (e.g., sample data and template code).

What will you build?

The course starts off by developing a simple web server. Think, high-level transformations of requests into responses. It builds it from the ground up and then layers a simple RESTful API for a fictitious wildlife reserve on top.

They start off with the simplest thing, a function that transforms one specific request into one specific response, and then move up all the way to actually serving the API over HTTP.

The goal, as often stated in the course, is not to replace an established and much more robust web server like Cowboy or a framework like Phoenix. At all.

Instead, it serves two pedagogical purposes. First, it teaches you how to use the language to solve a fairly complex problem. Second, it gives you a deeper understanding of how the production-ready tools you are going to adopt actually work within.

This approach is endemic to their teaching method. For example, they’ll develop a simple web server and API from scratch and then show you how similar it is to the equivalent Phoenix version. By the time you hit module 17 on Phoenix, you don’t quite know Phoenix but it should feel oddly familiar. After all, you built a naïve/simplified version of the same controllers, router, templates, etc. from scratch. This is, of course, a deliberate choice.

The same is true when they implement a simple GenServer from scratch and then are able to seamlessly replace it with the real deal (with use GenServer). Yes, you developed the Fisher-Price version of the production-ready tools, but you now understand how they work under the hood. All before Mike and Nicole proceed to teach you how to use the battle-tested ones.

I’m a fan of this didactic approach and I think it will serve most people well.

What will you learn?

It might be surprising to some but this course does not provide the typical tour of data types and data structures available in the language.

Instead, it uses the language to build something from the beginning and, in the process, it quickly exposes you to a variety of concepts, including how to use common data types.

It doesn’t cover them thoroughly, however, so reading the Elixir tutorial on the official site would be very beneficial prior to or after taking this course.

The course starts off with several modules that are heavily focused on pattern matching. This is a good choice because pattern matching is one of the most valuable and pervasive features of Elixir.

As you would expect, there is also quite a bit of emphasis on immutable data structures, the pipe operator, recursion, and the Enum module.

In the process you’ll also learn a lot about IEx, Mix, organizing your code in a logical and idiomatic manner, defining Structs as the safer alternatives to maps, and comprehensions. 

Testing is covered adequately but not extensively in its own module. Not in a TDD manner from the very start of the course like they did in some of their previous courses. This has, again, didactical advantages even if you choose to adopt TDD in your actual work.

In the second half of the course, things get a little more serious courtesy of OTP, delving deeper into working with sockets, the actor model, Task, GenServer, and linking and monitoring processes.

Other points worth making

In more or less random order:

• The course is up to date to Elixir 1.10.x, somewhat rare among Elixir courses. Some of the videos show Mike and Nicole using a previous version (i.e., 1.5), but the Notes use the latest version and the rare differences are noted.  For example, the video shows the old mix new project format which included a config folder. In their hands-on notes for the video, they have a comprehensive “I don’t see a config directory” section to address it. You’re basically never lost or confused due to version discrepancies.
• The overall quality is excellent. It’s a really polished product in terms of audio, video, text, and visuals used to aid in explaining the more conceptual parts.
• They answer the overwhelming majority of your “wait a second” questions and objections. Either later in the video or right in the notes for that particular module. They genuinely anticipate most questions, which is the hallmark of a great course.
• Most modules have a single 5-15 minute video, but some modules include two videos. So the modules are… well, modular.
• Although this course will equip you to start studying Phoenix, it doesn’t really cover the subject. There is a module, as I mentioned, which is just enough to whet your appetite for the framework.
• Erlang interoperability is at least in part addressed in module 20, where sample code from the documentation of gen_tcp is converted from Erlang to Elixir code.
• The course is full of small tips like enabling command history in IEx (with export ERL_AFLAGS="-kernel shell_history enabled"), speeding up unit tests by making them asynchronous (i.e., use ExUnit.Case, async: true), using flush() to clear a process’ mailbox, etc.

Is it worth the price?

At $89, Developing with Elixir/OTP is not your average Udemy course that’s routinely discounted to $12. That’s because it’s not your average course.

If I had to rate it, I’d give it a 4.5 out of 5. I highly recommend it to working programmers who are interested in picking up Elixir quickly.

I would argue that it’s a great, current resource that is well worth the price of admission if you favor learning from videos.

The post Developing with Elixir/OTP Course Review appeared first on Programming Zen.

Recently I rewrote the backend for my service, Any New Books, due to an Amazon API change. Generally speaking, rewriting an entire codebase is a bad idea. However, the code was quite old and the API changes rather drastic, so I took the opportunity to rewrite the whole thing in Rails 6.

This service allows you to subscribe (100% for free) to categories of your choosing and then receive a weekly email for each category with a selection of newly released books.

In the backend, the algorithm uses a few heuristics to determine how to present new books for a given category, so that the best candidates surface to the top to be manually selected by a (human) editor.

Sorting results by specific values with CASE

One of the parameters to consider is, believe it or not, whether a book’s binding is hardcover, paperback, Kindle, or audiobook. So at some point, I needed to sort results by these specific values in SQL.

In the backend I rely on PostgreSQL, so I used the following simple case statement:

SELECT *
FROM   books
ORDER  BY CASE binding
            WHEN 'Hardcover' THEN 1
            WHEN 'Paperback' THEN 2
            WHEN 'Kindle Edition' THEN 3
            WHEN 'Audiobook' THEN 4
            ELSE 5
          END

This will order books placing hardcover books first, then paperbacks, then Kindle Edition ones, then audiobooks. And if a book has a binding/format that was not included in the list (e.g., MP3 CD), it will be placed last.

SQL CASE statements like this are quite handy and will work in the majority of modern relational databases.

Ordering by multiple fields

This is cool, but can we do if we also want independently published books (whose publisher in the database is “Independently Published”) to appear first in the list? (Hey, let’s throw a bone to the indie crowd.)

That has nothing to do with binding used as the condition for the CASE statement; it’s another field altogether. 

Here is what we cannot do:

SELECT *
FROM   books
ORDER  BY publisher,
          CASE binding
            WHEN 'Hardcover' THEN 1
            WHEN 'Paperback' THEN 2
            WHEN 'Kindle Edition' THEN 3
            WHEN 'Audiobook' THEN 4
            ELSE 5
          END

I mean, that will execute. But a book published by “Acme” will appear before independently published books which is not what we want. Likewise, if we use ORDER BY publisher DESC, ... books published by, say, “Wrox” will appear before independently published ones. (Wrox books tend to be great but still, it’s not what we want.)

You might be tempted to comma separate two CASE statements, one to sort by publisher and the existing one to sort by binding. Thankfully we don’t have to do that. There is a much simpler way using a single CASE statement:

SELECT *
FROM   books
ORDER  BY CASE
            WHEN publisher = 'Independently Published' THEN 1
            WHEN binding = 'Hardcover' THEN 2
            WHEN binding = 'Paperback' THEN 3
            WHEN binding = 'Kindle Edition' THEN 4
            WHEN binding = 'Audiobook' THEN 5
            ELSE 6
          END

The LIKE operator in a CASE statement

We can even inject a LIKE operator to pick up books whose publishers contain the string “Independent”:

SELECT *
FROM   books
ORDER  BY CASE
            WHEN publisher LIKE '%Independent%' THEN 1
            WHEN binding = 'Hardcover' THEN 2
            WHEN binding = 'Paperback' THEN 3
            WHEN binding = 'Kindle Edition' THEN 4
            WHEN binding = 'Audiobook' THEN 5
            ELSE 6
          END

Thanks to the ILIKE variant, we can make the LIKE operator case insensitive:

SELECT *
FROM   books
ORDER  BY CASE
            WHEN publisher ILIKE '%independent%' THEN 1
            WHEN binding = 'Hardcover' THEN 2
            WHEN binding = 'Paperback' THEN 3
            WHEN binding = 'Kindle Edition' THEN 4
            WHEN binding = 'Audiobook' THEN 5
            ELSE 6
          END

There you have it!

This is basic stuff, no two ways about it. Lately, though, I’ve been reflecting more on the fact that what’s basic to me might not be so basic to people who are just starting out.

As a result, I want to share more on this blog and hope that in doing so, I will help someone, somewhere. Make sure you subscribe below if you are interested in seeing further content like this.

The Art of PostgreSQL is amazing

While we are on the topic, I cannot stress my recommendation for The Art of PostgreSQL highly enough. It houses fantastic content for those who already have a basic understanding of SQL and wish to take their knowledge of PostgreSQL (and SQL in general) to the next level.

The post Sorting Results by Specific Values in SQL with CASE appeared first on Programming Zen.

Simple enough, but there is more than meets the eye.

Elixir String Length

In Elixir, you can return the number of characters in a string with the String.length/1 function:

String.length("Antonio") # 7
String.length("")        # 0
String.length("résumé")  # 6

Discussion

In the case of a string like, "Antonio", there isn’t much to discuss. String.length("Antonio") returns the number of characters in the string.

The string clearly has 7 characters and since each character in this particular string can be represented with a single byte, its raw representation is 7 bytes as well.

Things become more interesting when a string contains special characters.

Consider the string, "résumé". In this case, String.length/1 returns 6. You can think of this as the number of “visible” or “user-perceived” characters in the string. However, let’s investigate its raw representation:

iex(2)> i "résumé"
Term
  "résumé"
Data type
  BitString
Byte size
  8
Description
  This is a string: a UTF-8 encoded binary. It's printed surrounded by
  "double quotes" because all UTF-8 encoded code points in it are printable.
Raw representation
  <<114, 195, 169, 115, 117, 109, 195, 169>>
Reference modules
  String, :binary
Implemented protocols
  Collectable, IEx.Info, Inspect, List.Chars, String.Chars

You’ll notice that the string’s actual data type is BitString. Specifically, this binary is made up of 8 bytes, even though there are only 6 user-perceived characters. This is because it takes 2 bytes to represent its accented é characters.

If you are interested in the number of bytes within a string, instead of its length, you can use the Kernel.byte_size/1 function:

iex(3)> string = "résumé"
"résumé"

iex(4)> String.length(string)
6

iex(5)> byte_size(string)
8

From a performance standpoint, it’s worth noting that Kernel.byte_size/1 is more efficient than String.length/1. Unlike the latter, which takes longer as the string grows, Kernel.byte_size/1 will return in constant time.

Strings in Elixir are UTF-8 encoded binaries. You can think of them as collections of code points. A code point is a Unicode character, whose underlying representation might require one or more bytes. For example, the é characters in the string "résumé" are code points whose representation requires two bytes each.

The Unicode standard also defines some special characters as the combination of other characters. In other words, even though they appear to the reader as a single character, they are in fact a combination of two or more code points. These are known as grapheme clusters.

For example, the e-acute letter can be represented as a single code point as we’ve done so far (this is also known as a precomposed character) or as a combination of two code points (the letter e and a combining acute accent). These look the same but they are technically two different characters as far as Elixir is concerned; so the two strings below end up representing two different binaries:

iex(6)> "é" == "é"
false

When working with strings, you’ll often want to consider them in terms of the user-perceived characters, rather than their code points or the binary they actually represent.

To help us out, the Elixir String module provides us with String.graphemes/1 which returns a list of characters, without splitting grapheme clusters into the underlying code points. If you need the codepoints, you can always use String.codepoints/1.

To see the distinction between code points and graphemes in action, consider the following string (using the grapheme cluster built from two code points):

iex(7)> String.codepoints("cliché")
["c", "l", "i", "c", "h", "e", "́"]

iex(8)> String.graphemes("cliché")
["c", "l", "i", "c", "h", "é"]

As you can see, String.codepoints/1 shows us a list of code points in the string, and the special e-acute gets split into two code points. If you look closely, you’ll notice the accent as the last code point in the list.

String.graphemes/1 simply returns the list of graphemes and is the closest thing that we have to a function that provides a list of user-perceived characters.

Now, consider its length and byte size:

ie(9)> String.length("cliché")
6

iex(10)> byte_size("cliché")
8

String.length/1 returns 6, the number of user-perceived characters in the string. Kernel.byte_size/1 returns 8 because it takes 3 bytes to represent the special character/grapheme (1 for the letter e, and 2 for the combining acute accent).

We used the expression “visible” or “user-perceived” characters to give us an intuitive understanding. Now that you know more about bytes, code points, and graphemes, we can be a little more precise and say that String.length/1 returns the number of graphemes in a string.

Finally, if you wanted to know the number of codepoints, you could trivially compose the Kernel.length/1 function and the String.codepoints/1 function:

"cliché"
  |> String.codepoints()
  |> length()

Note that if you are trying this in IEx, you’ll need to use the backslash character to continue on new lines:

iex(11)> "cliché" \
...(11)> |> String.codepoints() \
...(11)> |> length()
7

So in summary, our string contains 6 graphemes, 7 code points, and 8 bytes.

The post String Length in Elixir appeared first on Programming Zen.

As you likely know, a Hello World is a very simple program that displays the phrase, Hello, World!

Our Elixir Hello World might not be too exciting but it will allow us to discuss quite a few fundamental concepts.

Hello World in Elixir

As you might expect, this is very straightforward:

IO.puts("Hello, World!")

How to run it

The easiest way to run this line of code is to launch IEx (i.e., Interactive Elixir). This will also act as a sanity test to ensure that you have installed Elixir correctly on your machine.

$ iex
Erlang/OTP 22 [erts-10.4.4] [source] [64-bit] [smp:8:8] [ds:8:8:10] [async-threads:1] [hipe] [dtrace]

Interactive Elixir (1.9.1) - press Ctrl+C to exit (type h() ENTER for help)
iex(1)> 

For the best experience on Windows, including tab-based autocompletion in IEx, it’s worth passing the --werl flag to IEx or permanently enabling it by setting the environment variable IEX_WITH_WERL to true.

C:\> iex --werl

Once you type your Elixir Hello World and press enter, IEx will print out the message Hello, World! and then display the return value of the function, which is the atom :ok¹ (indicating that the function executed successfully):

iex(2)> IO.puts("Hello, World!")
Hello, World!
:ok
iex(3)>

Alternatively, you could place our one-liner in a hello.exs file and execute it as a script:

$ elixir hello.exs
Hello, World!

You could also create a whole (Mix) project for this, but arguably that is overkill for our humble Hello World.

Discussion

puts is a function that prints a message and adds a newline character. write is the variant that does the same but doesn’t append a newline. They both belong to the IO module, a module that includes, as the name implies, various functions for handling input and output.

At any time, we can learn more about a function by using the h helper within IEx:

iex(3)> h IO.puts

                        def puts(device \\ :stdio, item)

  @spec puts(device(), chardata() | String.Chars.t()) :: :ok

Writes item to the given device, similar to write/2, but adds a newline at the
end.

By default, the device is the standard output. It returns :ok if it succeeds.

## Examples

    IO.puts("Hello World!")
    #=> Hello World!

    IO.puts(:stderr, "error")
    #=> error

iex(4)>

Unlike languages like Python and Ruby, in Elixir you need to use a qualified call that includes the module name in order to invoke this function.

If we don’t qualify the call, we get a compile error:

iex(4)> puts("Hello, World!")
** (CompileError) iex:1: undefined function puts/1

If you wanted to omit the module name, you could import the module (i.e., import IO) beforehand, or more realistically, limit the import to the function(s) that you need:

import IO, only: [puts: 1]

puts("Hello, World!")

That puts: 1 indicates that we are specifically importing the version of the function that accepts one argument. You’ll see that function referred to as IO.puts/1 and we say that it has an arity of one or it’s a one-arity function.

The arity of a function (i.e., the number of arguments it accepts) is important because in Elixir you can have functions with the same name but different arities.

In fact, there are technically two variants of the puts function, IO.puts/1 which we just used, and IO.puts/2 which also allows us to specify an IO device as its first argument. (I say technically because they are both declared within a single function definition.)

By default, the function prints to the standard output. This can be easily verified by looking at the Elixir source code:

def puts(device \\ :stdio, item) do
  :io.put_chars(map_dev(device), [to_chardata(item), ?\n])
end

As you can see, the underlying implementation makes a call to the Erlang’s IO.put_chars/2 function.

What’s worth noting here is that:

• In Elixir, default parameters can be specified using \\.
• The default IO device for the function is the atom :stdio which maps to :standard_io in Erlang. Basically, by default, it will print to your stdout unless you pass a different device to the function.
• Another common value for the device is :stderr which is a shortcut for Erlang’s :standard_error.
• When we call the function without a device (leveraging the default parameter) we are calling IO.puts/1. When we pass it a device as its first argument and a string as its second argument, we are calling IO.puts/2.

In practice, you’ll most commonly use IO.puts/2 when printing to the standard error, instead of the standard output:

iex(5)> IO.puts(:stderr, "Hello, Post-Apocalyptic World!")
Hello, Post-Apocalyptic World!
:ok

For such messages, there are also IO.warn/1 (used below) and IO.warn/2 which output to the standard error and in addition, include a stacktrace (provided by the developer in the case of IO.warn/2).

iex(6)> IO.warn("Hello, Post-Apocalyptic World!")
warning: Hello, Post-Apocalyptic World!
  (stdlib) erl_eval.erl:680: :erl_eval.do_apply/6
  (elixir) src/elixir.erl:275: :elixir.eval_forms/4
  (iex) lib/iex/evaluator.ex:257: IEx.Evaluator.handle_eval/5
  (iex) lib/iex/evaluator.ex:237: IEx.Evaluator.do_eval/3
  (iex) lib/iex/evaluator.ex:215: IEx.Evaluator.eval/3

:ok

In most cases, parentheses are optional in Elixir, so we could omit them.²

IO.puts "Hello, World!"

It’s worth noting that strings are double-quoted literals in Elixir. Unlike other languages, single-quoted literals are not an alternative way of representing strings.

In Elixir, single-quoted literals represent a related but ultimately different datatype (i.e., List), as we can verify by using the handy data type information helper i in IEx:

iex(7)> i "Hello, World!"
Term
  "Hello, World!"
Data type
  BitString
Byte size
  13
Description
  This is a string: a UTF-8 encoded binary. It's printed surrounded by
  "double quotes" because all UTF-8 encoded code points in it are printable.
Raw representation
  <<72, 101, 108, 108, 111, 44, 32, 87, 111, 114, 108, 100, 33>>
Reference modules
  String, :binary
Implemented protocols
  Collectable, IEx.Info, Inspect, List.Chars, String.Chars

iex(8)> i 'Hello, World!'
Term
  'Hello, World!'
Data type
  List
Description
  This is a list of integers that is printed as a sequence of characters
  delimited by single quotes because all the integers in it represent printable
  ASCII characters. Conventionally, a list of Unicode code points is known as a
  charlist and a list of ASCII characters is a subset of it.
Raw representation
  [72, 101, 108, 108, 111, 44, 32, 87, 111, 114, 108, 100, 33]
Reference modules
  List
Implemented protocols
  Collectable, Enumerable, IEx.Info, Inspect, List.Chars, String.Chars
iex(9)>

Strings are encoded in UTF-8, so you can use special characters and even emojis.

iex(9)> IO.puts("Fabrizio De André")
Fabrizio De André
:ok

iex(10)> IO.puts("Hello, 🌎!")
Hello, 🌎!
:ok

It’s also possible to print a given character by specifying its UTF-8 codepoint.

iex(11)> > IO.puts("Hello, #{<<127758 :: utf8>>}!")
Hello, 🌎!
:ok

If you are familiar with Ruby, you’ll recognize the same string interpolation syntax in which the expression that needs to be evaluated is enclosed within #{}.

Windows users encountering issues related to special characters can improve their experience by changing the active console code page by executing chcp 65001 in their Command Prompt, before executing IEx.

It doesn’t get any simpler than a Hello World program, but as you can see, if you dig a little deeper, you can find out quite a few things about a given programming language.

In the next Elixir-related post, I’ll publish a similar discussion for another seemingly trivial problem: the length of a string in Elixir. It will give us an opportunity to discuss strings more deeply. Subscribe, if you don’t already, to be notified of its publication.

Footnotes

1. Atoms are constants whose values are their own names. The value of :ok is :ok. If you are familiar with Ruby, atoms are equivalent to symbols.
2. A glaring exception to the parentheses being optional are non-qualified/local calls with zero-arity. In those cases, parentheses are required to distinguish simple variables (e.g., user_list) from actual function calls (e.g., list_user()). To avoid ambiguity, it’s also important to include parentheses with one-arity functions within pipelines (e.g., "Hello, World!" |> IO.puts()). For stylistic recommendations of when to use parentheses and when to omit them, consider reading these two style guides (1, 2). At any rate, do not obsess over this. mix format or a properly configured editor will typically take care of applying idiomatic and consistent styling for you.

The post Elixir Hello World appeared first on Programming Zen.