29 Jul

The State of CSS Reflections

I recently saw this loader on CodePen, a pure CSS 3D rotating set of bars with a fading reflection. It's done by using an element for each bar, then duplicating each and every one of these elements to create the reflection and finally adding a gradient cover to create the fading effect. Which sounds a bit like scratching behind your right ear with the toes of your left foot! Not to mention the gradient cover method for the fading effect …

The State of CSS Reflections is a post from CSS-Tricks

29 Jul

Understanding Docker, Containers and Safer Software Delivery

Databases, dependencies, cron jobs … Applications today have so many layers that it isn't a surprise when moving things takes a lot of time. But it doesn't have to be that way. Today, you can ship software to virtually any environment, and be up and running in seconds. Enter Docker.

Software delivery

Delivering software used to be easy. The hard part was programming, but once you finished you would just handle the product, maybe fix some bugs, and that'd be all.

Later, with the "LAMP stack" (Linux, Apache, MySQL, PHP) --- which was widely supported by hosting companies --- things got slightly more complicated, but were still manageable. You could deliver dynamic sites linked to databases and set everything up via control panels.

But in more recent times, the scenario has gotten even more diverse and demanding, as new technologies have broken in. NoSQL databases and Node.js, programming languages like Python and Ruby, have gained in prominence. All of these and more have opened lots of possibilities, but now delivering software is not so easy anymore.

Implementation

Applications have become hard to implement. Even if you get yourself a dedicated server, you still have to deal with installing and settings things up, and even some of the maintenance that's needed to get everything up and running. And yet, with everything working, given that now you are in complex and tightly coupled systems with different services and programming languages, there's always the chance that things will break all of a sudden.

Docker to the rescue

Docker makes delivering software easy again. Docker allows you to set up everything --- the software you've developed, the OS in which it will run, the services that it needs, the modules and back-end tools such as cron jobs. All of it can be set up to run in minutes, with the guarantee that it will work on the target system as well as it works on your development environment.

The Problems Docker Solves

These are some of the issues you'll come across at some point or another when delivering software:

The application you carefully developed with your favorite language (Python, Ruby, PHP, C) doesn’t seem to work on the target system, and you can’t quite figure why. Everything was working just fine … until someone updated something on the server, and now it doesn’t anymore. An otherwise minor dependency (e.g. a module that’s used only occasionally, or a cron job) causes problems when your client uses the software … But it was working just fine on your computer when you tested it! A service your product relies on, like a database or a web server, has some problem (e.g. high traffic for a website, or some problematic SQL code) and acts as a bottleneck slowing down the entire system. A security breach compromises some component of the system and, as a result, everything goes down.

These issues fall within the somewhat fuzzy territory of "DevOps", with some of them involving maintenance issues (server updates), some testing issues (checking modules versions), and some deployment issues (installing and setting up everything on a different location). It's a real pain when deployment of something that's already working doesn't go smoothly, instead becoming problematic and time consuming.

Software Containers

You're probably familiar with those large, standardized shipping containers that exist to simplify delivery around the world --- the intermodal container:

You can put pretty much anything in one, ship it anywhere, and at the other end unload what's there --- a car, some furniture, a piano --- in exactly the same, original condition.

In software development, we may spend days trying to get things working on a different environment --- only for them to fail a couple of days later. It's easier and faster to ship a working car to a different continent than to deliver software that works reliably. Isn't that kind of embarrassing?

So people started thinking of something similar to shipping containers for delivering software --- something you could use to ship software in a reliable way, that would actually work as expected: software containers.

This might make you thinks of software installers, like those used to easily distribute desktop applications. With an installer, all you can distribute is an executable and some runtime libraries (small programs that the main application needs for running) --- as long as these don't conflict with those that the system has already installed. In contrast, software containers enable us to ship pretty much anything --- just as with physical containers.

Examples of what you can put in software containers include:

a Python, Ruby or PHP interpreter, packed with all of the required modules any runtime libraries specific versions of certain modules (because you never know when a newer version will cause some problems) services your application needs, like a web server or a database some specific tweaks for the system maintenance back end tools, such as cron jobs and other automation. Simplified operations

Containers simplify operations dramatically. And they're so practical, easy to create and easy to handle that there's no need to put everything into a single one.

You can put the core of your application with the libraries in one container, and call services such as Apache, MySQL or MongoDB, from different containers. This all may sound strange and even complicated, but bear with me and you'll see how doing so not only makes a lot of sense, but it's way easier that it sounds.

Continue reading %Understanding Docker, Containers and Safer Software Delivery%

29 Jul

Web Development Reading List #147: Security Guidelines, Accessible UI Compontens, And Content-First Design

   

When working in a team, it’s important to stick to rules. A common challenge is to build all your projects with a similar or the same toolset and coding guidelines. Only yesterday I discussed how we could port over a project that outgrew its initial codebase over the years to a fresh, React.js-based source code.

The decision for this wasn’t easy, since we had invested quite a lot of work and money into this project already, and a move to React would require quite some time, too. But since the switch makes sense from a technical perspective and the team is already using React for three other projects, we concluded that this would be a good step to do. It will enable more developers of the team to contribute to the project, to review code and to reduce the shift of technologies in the company. Occasionally, it’s time to re-evaluate your projects and move on.

The post Web Development Reading List #147: Security Guidelines, Accessible UI Compontens, And Content-First Design appeared first on Smashing Magazine.

29 Jul

Cross-Platform Native Apps With A Single Code Set Using Telerik NativeScript

   

Mobile applications are now a critical part of most enterprises, and there are many ways to create them, but what are the differences between these options and how do you choose between them? Do you choose to create native applications as Google and Apple intend? Do you choose to develop a mobile web hybrid application? Or do you find a middle ground?

We’re going to look at some of the common problems with developing mobile applications, both native and hybrid, and how NativeScript by Telerik fills the gap. We’ll proceed to develop a NativeScript Android and iOS application from scratch (using the supplied source code), and then convert the same application to use the bleeding-edge Angular 2 JavaScript framework.

The post Cross-Platform Native Apps With A Single Code Set Using Telerik NativeScript appeared first on Smashing Magazine.

29 Jul

Announcing The Versioning Podcast

A little over two years ago we launched Versioning, a free email newsletter to send our SitePoint readers daily tidbits mined from all over the web, to keep you amused, informed, and delighted. The response has been tremendous, and we're very proud of what we've built. Along the way we've had the chance to gather a lot of feedback, and we've been listening to what you're asking for.

Today we're excited to announce that we're taking Versioning to a whole new medium, and launching a podcast: The Versioning Show. Our goal is to keep you in touch with the people pushing the envelope on web design and development, mining their brains and sharing their insights and ideas so you can take your own work to the next level.

Think of The Versioning Show as an extra bonus publication just for you, that you can listen to anywhere, anytime, for free. In the spirit of the Versioning newsletter, we'll be keeping the shows short and to the point--usually around half an hour or so. We think that's just enough time to hear what someone cool is working on, and get inspired to go play with some new ideas.

The Hosts

The Versioning Show is hosted by two of our regular SitePoint contributors: Tim Evko and M. David Green. You may have seen their articles and watched their videos on SitePoint, or read their books and taken their courses on SitePoint Premium.

Tim Evko is a front-end developer, writer, and sometimes coherent thinker. You'll most likely hear him talking about performance, progressive enhancement, whiskey, large cuts of meat, or JavaScript. You can find him on Twitter at @tevko.

M. David Green enjoys creating articles, books, videos, and courses around JavaScript, CSS, semantic HTML, and agile engineering practices. He also coaches engineers through Agile That Works, and hosts the Hack the Process podcast. You can find him on Twitter at @mdavidgreen.

How to Get The Versioning Show

The Versioning Show is available right now as a podcast in the iTunes store, and we'll be releasing episodes with transcripts on SitePoint starting next week. We may be adding it to other podcast directories soon if you get in touch and let us know that there's interest. In the meantime, just search for Versioning in your favorite podcast listener, sit back and enjoy the show. (And be sure to leave feedback and a rating in iTunes to let us know what you think!)

Keep In Touch

If you're as excited about The Versioning Show as we are—and why wouldn't you be?—follow us right now on Twitter at @VersioningShow to get the latest information as soon as it comes out. You can also Tweet us there. And who knows, we may have something special planned in the coming weeks for our earliest and most loyal listeners who follow us there....

Continue reading %Announcing The Versioning Podcast%

29 Jul

Announcing The Versioning Podcast

A little over two years ago we launched Versioning, a free email newsletter to send our SitePoint readers daily tidbits mined from all over the web, to keep you amused, informed, and delighted. The response has been tremendous, and we're very proud of what we've built. Along the way we've had the chance to gather a lot of feedback, and we've been listening to what you're asking for.

Today we're excited to announce that we're taking Versioning to a whole new medium, and launching a podcast: The Versioning Show. Our goal is to keep you in touch with the people pushing the envelope on web design and development, mining their brains and sharing their insights and ideas so you can take your own work to the next level.

Think of The Versioning Show as an extra bonus publication just for you, that you can listen to anywhere, anytime, for free. In the spirit of the Versioning newsletter, we'll be keeping the shows short and to the point--usually around half an hour or so. We think that's just enough time to hear what someone cool is working on, and get inspired to go play with some new ideas.

The Hosts

The Versioning Show is hosted by two of our regular SitePoint contributors: Tim Evko and M. David Green. You may have seen their articles and watched their videos on SitePoint, or read their books and taken their courses on SitePoint Premium.

Tim Evko is a front-end developer, writer, and sometimes coherent thinker. You'll most likely hear him talking about performance, progressive enhancement, whiskey, large cuts of meat, or JavaScript. You can find him on Twitter at @tevko.

M. David Green enjoys creating articles, books, videos, and courses around JavaScript, CSS, semantic HTML, and agile engineering practices. He also coaches engineers through Agile That Works, and hosts the Hack the Process podcast. You can find him on Twitter at @mdavidgreen.

How to Get The Versioning Show

The Versioning Show is available right now as a podcast in the iTunes store, and we'll be releasing episodes with transcripts on SitePoint starting next week. We may be adding it to other podcast directories soon if you get in touch and let us know that there's interest. In the meantime, just search for Versioning in your favorite podcast listener, sit back and enjoy the show. (And be sure to leave feedback and a rating in iTunes to let us know what you think!)

Keep In Touch

If you're as excited about The Versioning Show as we are—and why wouldn't you be?—follow us right now on Twitter at @VersioningShow to get the latest information as soon as it comes out. You can also Tweet us there. And who knows, we may have something special planned in the coming weeks for our earliest and most loyal listeners who follow us there....

Continue reading %Announcing The Versioning Podcast%

28 Jul

Quick Tip: How to Throttle Scroll Events

One of the perils of listening to scroll events is performance degradation. The browser will execute the callback every single time the user scrolls, which can be many events per second. If the callback performs a bunch of repaints, this means bad news for the end user. Repaints are expensive, especially when you are redrawing large parts of the view, such as is the case when there is a scroll event.

The example below illustrates the issue:

See the Pen Unthrottled Scroll Events by SitePoint (@SitePoint) on CodePen.

Apart from performance degradation and being prone to causing seizures. This example illustrates what happens when the computer does exactly what you tell it to do. There is no smooth transition between background colors and the screen just flickers. Any hapless programmer may feel as if there is no hope left in this world. Isnʼt there a better way?

Regulating Events

One solution is to defer events and manage a bunch of them at once. There are two commonly used functions that can help us with this: throttle and debounce.

Throttle guarantees a constant flow of events at a given time interval, whereas debounce groups a flurry of events into one single event. One way to think about it is throttle is time-based and debounce is event driven. Throttling guarantees execution while debounce does not once grouping has occurred. If you want to know the specifics, check out this in-depth discussion of debounce versus throttling.

Debounce

Debounce solves a different problem, such as key presses with Ajax. When you type in a form, why would you send a request per keystroke? A more elegant solution is to group a burst of keystrokes into one event that will trigger the Ajax request. This fits within the natural flow of typing and saves server resources. With key presses, the interval between events isn't important, since users donʼt type at a constant rate.

Throttle

Since there are no guarantees with debounce, the alternative is to throttle the scroll events. Scrolling occurs on a given time span, so it is fitting to throttle. Once the user begins scrolling, we want to guarantee execution on a timely basis.

This technique helps with checking if we are at a specific part of the page. Given the size of the page, it takes many seconds to scroll through content. This enables throttling to fire the event only once at any given interval. Event throttling will make the scrolling experience smoother and guarantee execution.

Below is a poor manʼs event throttler in vanilla JavaScript:

Continue reading %Quick Tip: How to Throttle Scroll Events%

28 Jul

How to Deal with Distracting Housemates When Working from Home

After several years of working from home, I still encounter troubles from time to time. Housemates move in and move out, so every now and then boundaries have to be reestablished, and house responsibilities also shift around as our working hours change — it’s an ever-evolving system that we have to adapt to.

Now unless you share a home with other freelancers, your housemates aren’t going to empathize with your needs right off the bat. Learning how to communicate your needs is key, but you’ll also have to learn how to adapt to new surroundings, to make compromises on noise levels, responsibilities and so on.

If you find it hard to adapt to new surroundings or make compromises on living situations, don’t worry — I firmly believe that anyone can find a balance that suits them, and the folks they share a home with. Worst case scenario, you could always form a roommate agreement (which is a real thing by the way!).

BOUND-A-RIES!

You probably shouldn’t shout and/or enunciate the word (if you feel like you have to, you need new housemates), but you should definitely establish boundaries early on. A quick “heads up guys” in casual conversation is less awkward than “right, we need to have a chat” after a frustrating incident.

Distributing Responsibility

Everybody has to do their fair share of the housework, but between 9am and 5pm (or whatever your working hours are) you’re at work and others need to understand that. The same goes for other responsibilities such as babysitting (for those with a family) or even looking after house pets. Puppies especially need constant (almost 24/7) care, and the novelty of having one will soon wear off as the bank starts to run dry.

Make it clear that you’re happy to chip in with whatever needs to be done, but housemates need to understand that you do in fact have working hours like anybody else, that you’re not just “sitting around the house all day”. I wrote that in quotes because I’ve actually had this said to me several times!

So to summarize, working from home does not mean that:

You’re a stay-at-home wife/husband You have more time, henceforth you can have a dog/cat You’re able to do the majority of the housework You’re available because “you can work whenever, right?”

No, no, no and no!

Balancing Responsibilities and Flexible Hours

A common reason for working from home is “I’ll have more time to [insert fun activity here]”, but that’s rarely ever the case. In fact, you should be actively trying to reduce the amount of responsibilities that you have to ensure that your work comes first. When forming new work contracts you should fight for flexible hours — these will be a Godsend during an unexpected turn of events (things happen). Let’s say that your child needs a doctor but your partner is unable to drive today. Flexible hours means you can expect the unexpected.

If all else fails, you could always distribute responsibility via a quick game of Rock, Paper, Scissors, Lizard, Spock!

Having a Private Space

Whether your household has a child/dog/cat/lizard or not, your own office or room is always a useful thing to have. If you live in a particularly noisy household (or at least one that’s not dead silent), remember that it’s their space too, and a private room for yourself means your housemates can feel free (to an extent of course) in their own home — it benefits everyone.

Continue reading %How to Deal with Distracting Housemates When Working from Home%