You know, we use ad-blockers as well.
We gotta keep those servers running though. Did you know that we publish
useful books and run
friendly conferences — crafted for pros like yourself?
E.g. our upcoming SmashingConf New York, dedicated to smart front-end
techniques and design patterns.
This extended category features articles on client-side and server-side programming languages, tools, frameworks and libraries, as well as back-end issues. Experts and professionals reveal their coding tips, tricks and ideas. Curated by Dudley Storey and Rey Bango. Subscribe to the RSS-Feed.
Data visualization has become an important part of our everyday life, allowing us to quickly assess information. And with so many chart types out there to choose from, it should be possible to effectively solve almost any task, whether it's exploratory (i.e. researching and analyzing data to better understand it for yourself) or explanatory (i.e. reporting and communicating data to end users).
However, variety can also cause confusion, making it difficult to clearly understand the purpose of each form of data visualization. As a result, when an inappropriate type of chart is applied to data, the user not only might be confused by the information, but, more importantly, could make bad decisions based on such a presentation.
I started out as a web developer, and that's now one part of what I do as a full-stack developer, but never had I imagined I'd create things for the desktop. I love the web. I love how altruistic our community is, how it embraces open-source, testing and pushing the envelope.
I love discovering beautiful websites and powerful apps. When I was first tasked with creating a desktop app, I was apprehensive and intimidated. It seemed like it would be difficult, or at least… different.
Over the last five years, Node.js has helped to bring uniformity to software development. You can do anything in Node.js, whether it be front-end development, server-side scripting, cross-platform desktop applications, cross-platform mobile applications, Internet of Things, you name it. Writing command line tools has also become easier than ever before because of Node.js — not just any command line tools, but tools that are interactive, useful and less time-consuming to develop.
If you are a front-end developer, then you must have heard of or worked on Gulp, Angular CLI, Cordova, Yeoman and others. Have you ever wondered how they work?
In a world driven by the Internet, mobile apps need to share and receive information from their products' back end (for example, from databases) as well as from third-party sources such as Facebook and Twitter.
These interactions are often made through RESTful APIs. When the number of requests increases, the way these requests are made becomes very critical to development, because the manner in which you fetch data can really affect the user experience of an app.
Douglas Crockford famously declared browsers to be "the most hostile software engineering environment imaginable," and that wasn't hyperbole. Ensuring that our websites work across a myriad of different devices, screen sizes and browsers our users depend on to access the web is a tall order, but it's necessary.
If our websites don't enable users to accomplish the key tasks they come to do, we've failed them. We should do everything in our power to ensure our websites function under even the harshest of scenarios, but at the same, we can't expect our users to have the exact same experience in every browser, on every device.
I’ve been thinking a lot about speech for the last few years. In fact, it’s been a major focus in several of my talks of late, including my well-received Smashing Conference talk “Designing the Conversation.” As such, I’ve been keenly interested in the development of the Web Speech API.
When the Russian ruble's exchange rate slumped two years ago, it drove us to think of cutting hardware and hosting costs for the Mail.Ru email service. First, we had to take a look at what email consists of. Indexes and bodies account for only 15% of the storage size, whereas 85% is taken up by files. So, optimization of files (that is, attachments) is worth exploring in more detail.
At the time, we didn't have file deduplication in place, but we estimated that it could shrink the total storage size by 36%, because many users receive the same messages, such as price lists from online stores and newsletters from social networks that contain images and so on. In this article, I'll describe how we implemented a deduplication system under the guidance of PSIAlt.