There are times when you don’t have access to the internet. Be it during travel, on a plane, on a train, or during a layover. However, those are perfect opportunities to follow up on some of your favorite channels and clear up your long-overdue “Watch Later” playlist.
According to Stack Overflow’s Developer Survey 2019, Go is the third most wanted language to learn, as well as the third-best paid technology in the field. It is not a surprise, as it is one of the languages used for writing critical parts of a lot of large systems. The language design and syntax are simple, but developing in Go is far from easy.
As you probably know, source maps allow you to view source code context obtained from stack traces in their original, untransformed form. This view is particularly useful when attempting to debug minified code (like UglifyJS) or transpiled code (like TypeScript or ES6). We’ve made the analogy before, but source maps act as the decoder ring to your secret (minified or transpiled) code. As of recently, we support source maps for Node.js projects. Here’s what you need to know to generate and make those source maps available for Sentry.
Internet Explorer and Edge throw errors in the end user’s language. If your end user speaks Polish, they throw a Polish language error. If your end user speaks French, they throw a French language error. If your end user speaks German they throw a Spanish language error, but only if that end user accidentally set their Windows language to Spanish and they aren’t sure how to fix it; otherwise the error is in German.
One of the most mundane and frightening tasks for many developers is writing integration tests. It’s a time-consuming, fragile, and often difficult and frustrating task to accomplish. What makes it even worse is that it quickly gets out of hand and breaks often, which leads to frustration and dropping the idea completely.
If you’ve never tried functional programming development, I assure you that this is one of the best time investments you can make. You will not only learn a new programming language, but also a completely new way of thinking. A completely different paradigm.
If you love old architecture and castles, you’ll fall for Bratislava. Easily one of the most beautiful places you can visit in Europe, this Slovakian capital is small enough that you can drive/walk quickly to most places, but big enough to fill your schedule for a few days. It may surprise some to find out that, when it comes to software development, the area is very quickly becoming one of the European tech hubs. Last month, Bratislava hosted two big conferences in one week.
In an era of omnipresent frameworks, libraries and tooling, it may be hard to decide what tool to use and when. I know from experience, that the first thing you do, once you decide to write a module or CLI tool, is set up an environment. Some people love it, some hate it. But no matter on which side you are, you’ll most likely end up spending way too much time doing it, polishing every aspect of the setup.
Some may say that it is not possible to teach a person how to do “web development” in such a short period of time and I totally agree with it. But where does that magical point beyond which one knows how to do “web development” lay? I don’t know an answer to this question, but I think that those 28 days are enough to plant a small seed in a brain of a person who came there willing to learn — and that it will grow enormously if done correctly.
Working as a developer sometimes requires more knowledge than just of programming itself. It’s always a good idea to grasp some concepts from other IT fields as well. One of these concepts are file system permissions, proper management of which is a must when it comes to working with files, eg. using node.js fs module.
One of the greatest things about programming is that you can change stuff. You can modify them, shape, bend to your needs. But as good as it may sound, unfortunately it is a double-edged sword. Having the ability to change is tempting and dangerous at the same time.
When there is a problem, there is a solution. In XHTMLized we often say: if there is a solution - Kamil has it. Today we would like to share the first episode of “The Interviewed” with you. Under this name a series of conversations will be published on our blog. Conversations with developers, project managers, operational staff – and other spirits performing various roles in XHTMLized.
As awesome as Github’s web interface is, trying to use it alongside your terminal can be rather time consuming and may slow down your workflow. Why couldn’t you just perform all your common actions straight from the CLI? Well, you can. And it’s not just another homemade application. It comes straight from GitHub itself.
Git has become a popular version control system and one we’ve embraced. For a lot of dev teams though, starting to work with a brand new system raises a lot of questions, the most important being how to setup a good workflow. There are many opinions on this subject, and it takes time to wade through all of them. The “Forking with feature branches workflow” is one workflow that has been adopted by a very large crowd of open-source developers, including us.