Search icon CANCEL
Subscription
0
Cart icon
Your Cart (0 item)
Close icon
You have no products in your basket yet
Save more on your purchases! discount-offer-chevron-icon
Savings automatically calculated. No voucher code required.
Arrow left icon
Explore Products
Best Sellers
New Releases
Books
Videos
Audiobooks
Learning Hub
Free Learning
Arrow right icon

Tech Guides - Web Development

87 Articles
article-image-node-6-what-expect
Darwin Corn
16 Jun 2016
5 min read
Save for later

Node 6: What to Expect

Darwin Corn
16 Jun 2016
5 min read
I have a confession to make—I’m an Archer. I’ve taken my fair share of grief for this, with everyone from the network admin that got by on Kubuntu, to the C dev running Gentoo getting in on the fun. As I told the latter, Gentoo is for lazy people; lazy people that want to have their cake and eat it too with respect to the bleeding edge. Given all that, you’ll understand that when I was asked to write this post, my inner Archer balked at the thought of digging through source and documentation to distill this information into something palatable for your average back end developer. I crossed my fingers and wandered over to their GitHub, hoping for a clear roadmap, or at least a bunch of issues milestoned to 6.0.0. I was disappointed even though a lively discussion on dropping XP/Vista support briefly captured my attention. I’ve also been primarily doing front end work for the last few months. While I pride myself on being an IT guy who does web stuff every now and then (someone who cares more about the CI infrastructure than the product that ships), circumstances have dictated that I be in the ‘mockup’ phase for a couple volunteer gigs as well as my own projects, all at once. Convenient? Sure. Not exactly conducive to my generalist, RenaissanceMan self-image, though (as an aside, the annotations in Rap Genius read like a Joseph Ducreux meme generator). Back end framework and functionality has been relegated to the back of my mind. As such, I watched Node bring io.js back into the fold and go to Semver this fall with all the interest of a house cat. A cat that cares more about the mouse in front of him than the one behind the wall. By the time Node 6 drops in April, I’m going to be feasting on back end work. It would behoove me to understand the new tools I’ll be using. So I ignored the Archer on my left shoulder and, and listening to my editor on the right, dug around the source for a bit. Of note is that there’s nothing near as ground breaking as the 4.0.0 release, where Node adopted the ES6 support introduced in io.js 1.0.0. That’s not so much a slight at Node development as a reflection of the timeline of JavaScript development. That said, here’s some highlights from my foray into their issue tracker: Features Core support for Promises I’ve been playing around with Ember for so long that I was frankly surprised that Node didn’t include Core support for Promises. A quick look at the history of Node shows that they originally existed (based on EventEmitters), but that support was removed in 0.2 and ever since server-side promises have been the domain of various npm modules. The PR is still open, so it remains to be seen if the initial implementation of this makes it into 6.0.0. Changing FIPS crypto support In case you’re not familiar with the Federal Information Processing Standard, MDN has a great article explaining it. Node’s implementation left some functionality to be desired, namely that Node compiled with FIPS support couldn’t use nonFIPS hashing algorithms (md5 for one, breaking npm). Node 6 compiled with FIPS support will likely both fix that and flip it’s functionality, such that, by default, FIPS support will be disabled (in Node compiled with it), requiring invocation in order to be used. Replacing C http-parser and DNS resolvers with JS implementations ThesePRs are still open (and have been for almost a year) so I’d say seeing them come in 6.0.0 is unlikely, though the latest discussion on the latter seems centered around CI so I might be wrong on it not making 6.0.0. That being said, while not fundamentally changing functionality too much, it will be cool to see more of the codebase being written in JavaScript. Deprecations fs reevaluation This primarily affects pre-v4 graceful-fs, on which many modules, including major ones such as npm itself and less, are dependent. The problem lies not insofar as these modules are dependent on graceful-fs, as they don’t require v4 or newer. This could lead to breakage for a lot of Node apps whose developers aren’t on their game when it comes to keeping the dependencies up to date. As a set and forget kind of guy, I’m thankful this is just getting deprecated and not outright removed. Removals sys The sys module was deprecated in Node 4 and has always been deprecated in io.js. There was some discussion on its removal last summer, and it was milestoned to 6.0.0. It’s still deprecated as of Node 5.7.0, so we’ll likely have to wait until release to see if it’s actually removed. Nothing groundbreaking, but there is some maturation of the platform in both codebase and deprecations as well as outright removals. If you live on the bleeding edge like I do, you’ll hop on over to Node 6 as soon as it drops in April, but there’s little incentive to make the leap for those taking a more conservative approach to Node development. About the Author Darwin Corn is a Systems Analyst for the Consumer Direct Care Network. He is a mid-level professional with diverse experience in the Information Technology world.
Read more
  • 0
  • 0
  • 2021

article-image-beating-jquery-making-web-framework-worth-its-weight-code
Erik Kappelman
20 Apr 2016
5 min read
Save for later

Beating jQuery: Making a Web Framework Worth its Weight in Code

Erik Kappelman
20 Apr 2016
5 min read
Let me give you a quick disclaimer. This is a bit of a manifesto. Last year I started a little technology company with some friends of mine. We were lucky enough to get a solid client for web development right away. He was an author in need of a blogging app to communicate with the fans of his upcoming book. In another post I have detailed how I used Angular.js, among other tools, to build this responsive, dynamic web app. Using Angular.js is a wonderful experience and I would recommend it to anyone. However, Angular.js really only looks good by comparison. By this I mean, if we allow any web framework to exist in a vacuum and not simply rank them against one another, they are all pretty bad. Before you gather your pitchforks and torches to defend your favorite flavor let me explain myself. What I am arguing in this post is that many of the frameworks we use are not worth their weight in code. In other words, we add a whole lot of code to our apps when we import the frameworks, and then in practice using the framework is only a little bit better than using jQuery, or even pure JavaScript. And yes I know that using jQuery means including a whole bunch of code into your web app, but frameworks like Angular.js are many times built on top of jQuery anyway. So, the weight of jQuery seems to be a necessary evil. Let’s start with a simple http request for information from the backend. This is what it looks like in Angular.js: $http.get('/dataSource').success(function(data) { $scope.pageData = data; }); Here is a similar request using Ember.js: App.DataRoute = Ember.Route.extend({ model: function(params) { return this.store.find('data', params.data_id); } }); Here is a similar jQuery request: $.get( "ajax/stuff.html", function( data ) { $( ".result" ).html( data ); alert( "Load was performed." ); }); It's important for readers to remember that I am a front-end web developer. By this, I mean I am sure there are complicated, technical, and valid reasons why Ember.js and Angular.js are far superior to using jQuery. But, as a front-end developer, I am interested in speed and simplicity. When I look at these http requests and see that they are overwhelmingly similar I begin to wonder if these frameworks are actually getting any better. One of the big draws to Angular.js and Ember.js is the use of handlebars to ease the creation of dynamic content. Angular.js using handlebars looks something like this: <h1> {{ dynamicStuff }} </h1> This is great because I can go into my controller and make changes to the dynamicStuff variable and it shows up on my page. However, the following accomplishes a similar task using jQuery. $(function () { var dynamicStuff = “This is dog”; $(‘h1’).html( dynamicStuff ); }); I admit that there are many ways in which Angular.js or Ember.js make developing easier. DOM manipulation definitely takes less code and overall the development process is faster. However, there are many times that the limitations of the framework drive the development process. This means that developers sacrifice or change functionality simply to fit the framework. Of course, this is somewhat expected. What I am trying to say with this post is that if we are going to sacrifice load-times and constrict our development methods in order to use the framework of our choice can they at least be simpler to use? So, just for the sake of advancement lets think about what the perfect web framework would be able to do. First of all, there needs to be less set up. The brevity and simplicity of the http request in Angular.js is great, but it requires injecting the correct dependencies in multiple files. This adds stress, opportunities to make mistakes and development time. So, instead of requiring the developer to grab each specific tool for each specific implementation what if the framework took care of that for you? By this I mean if I were to make an http request like this: http( ‘targetURL’ , get , data) When the source is compiled or interpreted the needed dependencies for this http request are dynamically brought into the mix. This way we can make a simpler http request and we can avoid the hassle of setting up the dependencies. As far as DOM manipulation goes, the handlebars seem to be about as good as it gets. However, there needs to be better ways to target individual instances of a repeated elements such as <p> tags holding the captions in a photo gallery. The current solutions for problems like this one are overly complex. Especially when this issue involves one of the most common things on the internet, a photo gallery. About the Author As you can see, I am more of a critic than a problem solver. I believe the issues I bring up here are valid. As we all become more and more entrenched in the Internet of Things, it would be nice if the development process caught up with the standards of ease that end users demand.
Read more
  • 0
  • 0
  • 3105

article-image-adblocking-and-future-web
Sam Wood
11 Apr 2016
6 min read
Save for later

Adblocking and the Future of the Web

Sam Wood
11 Apr 2016
6 min read
Kicked into overdrive by Apple's iOS9 infamously coming with adblocking options for Safari, the content creators of the Internet have woken up to the serious challenge of ad-blocking tech. The AdBlock+ Chrome extension boasts over 50 million active users. I'm one of them. I'm willing to bet that you might be one too. AdBlock use is rising massively and globally and shows no sign of slowing down. Commentators have blamed the web-reading public, have declared web publishers have brought this on themselves and even made worryingly convincing arguments that adblocking is a conspiracy by corporate supergiants to kill the web as we know it. They all agree on one point though - the way we present and consume web content is going to have to evolve or die. So how might adblocking change the web? We All Go Native One of the most proposed and most popular solutions to the adblocking crisis is to embrace "native" advertising. Similar to sponsorship or product placement in other media, native advertising interweaves its sponsor into the body of the content piece. By doing so, an advert is made immune to the traditional scripts and methods that identify and block net ads. This might be a thank you note to a sponsor at the end of a blog, an 'advertorial' upsell of a product or service, or corporate content marketing where a company produces and promotes their own content in a bid to garner your attention for their paid products. (Just like this blog. I'm afraid it's content marketing. Would you like to buy a quality tech eBook? How about the Web Developer's Reference guide - your Bible for everything you need to know about web dev! Help keep this Millennial creative in a Netflix account and pop culture tee-shirts.) The Inevitable Downsides Turns out nobody wants to read sponsored content - only 24% of readers scroll down on a native ad. A 2014 survey by Contently revealed two-thirds of respondents saying they felt deceived by sponsored advertising. We may see this changing. As the practice becomes more mainstream, readers come to realize it does not impact on quality or journalistic integrity. But it's a worrying set of statistics for anyone who hoped direct advertising might save them from the scourge of adblock. The Great App Exodus There's a increasingly popular prediction that adblocking may lead to a great exodus of content from browser-based websites to exist more and more in a scattered app-based ecosystem. We can already see the start of this movement. Every major content site bugs you to download its dedicated app, where ads can live free of fear. If you consume most of your mobile media through Snapchat Discover channels, through Facebook mobile sharing, or even through IM services like Telegram, you'll be reading your web content in that apps dedicated built-in reader. That reader is, of course, free of adblocking extensions. The Inevitable Downsides The issue here is one of corporate monopoly. Some journalists have criticized Facebook Instant (the tech which has Facebook host articles from popular news sites for increased load times) for giving Facebook too much power over the news business. Vox's Matthew Yglesias's predicts restructuring where "instead of digital media brands being companies that build websites, they will operate more like television studios — bringing together teams that collaborate on the creation of content, which is then distributed through diverse channels that are not themselves controlled by the studio." The control that these platforms could exert raises troubling concerns for the future of the Internet as a bastion of free and public speech. User Experience with Added Guilt Alongside adding advertising <script> tags, web developers are increasingly creating sites that detect if you're using AdBlocking software and punishing you accordingly. This can take many forms - from a simple plea to be put on your whitelist in order to keep the servers running, to the cruel and inhuman: Some sites are going as far as actively blocking content for users using adblockers. Trying accessing an article on the likes of Forbes or CityAM with an adblocker turned on. You'll find yourself greeted with an officious note and a scrambled page that refuses to show you the goods unless you switch off the blocker. The Inevitable Downsides No website wants to be in a position where it has to beg or bully their visitors. Whilst your committed readers might be happy to whitelist your URL, antagonizing new users is a surefire way to get them to bounce from the site. Sadly, sabotaging their own sites for ad blocking visitors might be one of the most effective ways for 'traditional' web content providers to survive. After all, most users block ads in order to improve their browsing experience. If the UX of a site on the whitelist is vastly superior to the UX under adblock, it might end up being more pleasant to browse with the extension off. An Uneasy Truce between Adblockers and Content In many ways adblocking was a war that web adverts started. From the pop-up to the autoplaying video, web ad software has been built to be aggressive. The response of adblockers is an indiscriminate and all-or-nothing approach. As Marco Arment, creator of the Peace adblocking app, notes "Today’s web readers [are so] fed up that they disable all ads, or even all Javascript. Web developers and standards bodies couldn’t be more out of touch with this issue, racing ahead to give browsers and Javascript even more capabilities without adequately addressing the fundamental problems that will drive many people to disable huge chunks of their browser’s functionality." Both sides need to learn to trust one another again. The AdBlock+ Chrome extension now comes with an automatic whitelist of sites; 'guilt' website UX works to remind us that a few banner ads might be the vital price we pay to keep our favorite mid-sized content site free and accessible. If content providers work to restore sanity to the web on their ends, then our need for adblocking software as users will diminish accordingly. It's a complex balance that will need a lot of good will from both 'sides' - but if we're going to save the web as we know it, then a truce might be necessary. Building a better web? How about checking out our Essential Web Dev? Get five titles for only $50!  
Read more
  • 0
  • 1
  • 2071
Banner background image

article-image-future-service
Edward Gordon
07 Apr 2016
5 min read
Save for later

The Future as a Service

Edward Gordon
07 Apr 2016
5 min read
“As a Service” services (service2?) generally allow younger companies to scale quickly and efficiently. A lot of the hassle is abstracted away from the pain of implementation, and they allow start-ups to focus on the key drivers of any company – product quality and product availability. For less than the cost of proper infrastructure investment, you can have highly-available, fully distributed, buzzword enabled things at your fingertips to start running wild with. However, “as a Service” providers feel like they’re filling a short-term void rather than building long-term viable option for companies. Here’s why. 1. Cost The main driver of SaaS is that there’s lower upfront costs. But it’s a bit like the debit card versus credit card debate; if you have the money you can pay for it upfront and never worry about it again. If you don’t have the money but need it now, then credit is the answer – and the associated continued costs. For start-ups, a perceived low-cost model is ideal at first glance. With that, there’s the downside that you’ll be paying out of your aaS for the rest of your service with them, and moving out of the ecosystem that you thought looked so robust 4 years ago will give the sys admin that you have to hire in to fix it nightmares. Cost is a difficult thing to balance, but there’s still companies still happily running on SQL Server 2005 without any problems; a high upfront cost normally means that it’s going to stick around for ages (you’ll make it work!). To be honest, for most small businesses, investment in a developer who can stitch together open source technologies to suit your needs will be better than running to the closest spangly Service provider. However, aaS does mean you don’t need System Administrators stressing about ORM-generated queries. 2. Ownership of data An under-discussed but vital issue that lies behind the aaS movement is the ownership of data, and what this means to companies. How secure are the bank details of your clients? How does the aaS provider secure against attacks? Where does this fit in terms of compliance? To me, the risks associated with giving your data for another company to keep is too high to justify, even if it’s backed up by license agreements and all types of unhackable SSL things (#Heartbleed). After all, a bank is more appealing to thieves than a safe behind a picture in your living room. Probably*. As a company, regardless of size, your integrity is all. I think you should own that. 3. The Internet as kingmaker We once had an issue at the Packt office where, during a desk move, someone plugged an Internet cable (that’s the correct term for them, right?) from one port to another, rather than into their computer. The Internet went down for half the day without anyone really knowing what was going on. Luckily, we still had local access to stuff – chapters, databases, schedules, and so on. If we were fully bought into the cloud we would have lost a collective 240 man hours from one office because of an honest mistake. Using the Internet as your only connection point to the data you work with can, and will, have consequences for businesses who work with time-critical pieces of data. This leaves an interesting space open that, as far as I’m aware, very few “as a Service” providers have explored; hybrid cloud. If the issue, basically, is the Internet and what cloud storage means to you operationally and in terms of data compliance, then a world where you can keep sensitive and “critical” data local while keeping bulk data with your cloud provider, then you can leverage the benefits of both worlds. The advantages of speed and lack of overheads would still be there, as well as the added security of knowing that you’re still “owning” your data and your brand reputation. Hybrid clouds generally seem to be an emergent solution in the market at large. There are even solutions now on Kickstarter that provide you with a “cloud” where you own your data. Lovely. Hell, you can even make your own PaaS with Chef and Docker. I could go on. The quite clear popularity of “as a Service” products means there’s value in the services they’re offering. At the moment though, there’s enough problems inherent in adoption to believe that they’re a stop-gap to something more finite. The future, I think, lies away from the black and white of aaS and on-premises software. There’s advantages in both, and as we continue to develop services and solutions that blend the two, I think we’re going to end up at a more permanent solution to the argument. *I don’t actually advocate the safe behind a picture method. More of a loose floorboard man myself. From 4th-10th April, save 50% on 20 of out top cloud titles. From AWS to Azure and OpenStack - and even Docker for good measure - learn how to build the services of tomorrow. If one isn't enough, grab 5 for just $50! Find them here.
Read more
  • 0
  • 0
  • 1574

article-image-angularjs-nodejs-and-firebase-startup-web-developers-toolkit
Erik Kappelman
09 Mar 2016
7 min read
Save for later

Angular.js, Node.js, and Firebase: the startup web developer's toolkit

Erik Kappelman
09 Mar 2016
7 min read
So, you’ve started a web company. You’ve even attracted one or two solid clients. But now you have to produce, and you have to produce fast. If you’ve been in this situation, then we have something in common. This is where I found myself a few months ago. A caveat: I am a self-taught web developer in an absolute sense. Self-taught or not, in August of 2015 I found myself charged with creating a fully functional blogging app for an author. Needless to say, I was in over my head. I was aware of Node.js, because that had been the backend for the very simple static content site my company had produced first. I was aware of database concepts and I did know a reasonable amount of JavaScript, but I felt ill prepared to pull of these tools together in a cohesive fashion. Luckily for me it was 2015 and not 1998. Today, web developers are blessed with tools that make the development of websites and web apps a breeze. After some research, I decided to use Angular.js to control the frontend behavior of the website, Node.js with Express.js as the backend, and Firebase to hold the data. Let me walk you through the steps I used to get started. First of all, if you aren’t using Express.js on top of Node.js for your backend in development you should start. Node.js was written in C, C++ and JavaScript by Ryan Dahl in 2009. This multiplatform runtime environment for JavaScript is fast, open-source, and easy to learn, because odds are you already know JavaScript. Using Express.js and the Express-Generator in congress with Node.js makes development quite simple. Express.js is Node middleware. In simple terms, Express.js makes your life a whole lot easier by doing most of the work for you. So, let’s build our backend. First, install Node.js and NPM on your system. There are a variety of online resources to complete this step. Then, using NPM, install the Express application generator. $ npm install express-generator -g Once we have Node.js and the Express generator installed, get to your development folder and execute the following commands to build the skeleton of your web app’s backend: $ express app-name –e I use the –e flag to set the middleware to use ejs files instead of the default jade files. I prefer ejs to jade but you might not. This command will produce a subdirectory called app-name in your current directory. If you navigate into this directory and type the commands $ npm install $ npm start and then navigate in a browser to http://localhost:3000 you will see the basic welcome page auto generated by Express. There are thousands of great things about Node.js and Express.js and I will leave them to be discovered by you as you continue to use these tools. Right now, we are going to get Firebase connected to our server. This can serve as general instructions for installing and using Node modules as well. Head over to firebase.com and create a free account. If you end up using Firebase for a commercial app you will probably want to upgrade to a paid account, but for now the starter account should be fine. Once you get your Firebase account setup, create a Firebase instance using their online interface. Once this is done get back to your backend code to connect the Firebase to your server. First install the Firebase Node module. $ npm install firebase --save Make sure to use the --save flag because this puts a new line in your packages.json file located in the root of the web server. This means that if you type npm install, as you did earlier, NPM will know that you added firebase to your webserver and install it if it is not already present. Now open the index.js file in the routes folder in the root of your Node app. At the top of this folder, put in the line var Firebase = require(‘firebase’); This pulls the Firebase module you installed into your code. Then to create a connection to the account you just created on Firebase[MA1]  ,put in the following line of code: var FirebaseRef = new Firebase("https://APP-NAME.firebaseio.com/"); Now, to take a snapshot in JSON of your Firebase and store it in an object, include the following lines var FirebaseContent = {}; FirebaseRef.on("value", function(snapshot) { FirebaseContent = snapshot.val(); }, function(errorObject) { console.log("The read failed: " + errorObject.code); }); FirebaseContent is now a JavaScript object containing your complete Firebase data. Now let’s get Angular.js hooked up to the frontend of the website and then it’s time for you to start developing. Head over to angularjs.org and download the source code or get the CDN. We will be using the CDN. Open the file index.ejs in the views directory in your Node app’s root. Modify the <head> tag, adding the CDN. <head> <script src="https://ajax.googleapis.com/ajax/libs/angularjs/1.5.0-rc.1/angular.min.js"></script> </head> This allows you to use the Angular.js tools. Angular.js uses controllers to control your app. Let’s make your angular app and connect a controller. Create a file called myapp.js in your public/javascripts directory. In myapp.js include the following angular.module(“myApp”,[]); This file will grow but for now this is all you need. Now create a file in the same directory called myController.js and put this code into it. Angular.module(“myApp”).controller(‘myController’,['$scope',function($scope){ $scope.jsVariable = 'Controller is working'; }]) Now modify the index.ejs file again. <html ng-app=“myApp”> <head> <script src="https://ajax.googleapis.com/ajax/libs/angularjs/1.5.0-rc.1/angular.min.js"></script> <script src="/javascripts/myApp.js"></script> <script src="/javascripts/myController.js"></script> </head> <body ng-controller= “myController”> <h1> {{jsVariable}} </h1> </body> </html> If you start your app again and go back to http://localhost:3000 you should see that your controller is now controlling the contents of the first heading. This is just a basic setup and there is much more you will learn along the way. Speaking from experience, taking the time to learn these tools and put them into use will make your development faster and easier and your results will be of much higher quality. About the Author Erik was born and raised in Missoula, Montana. He attended the University of Montana and received a degree in economics. Along the way, he discovered the value of technology in our modern world, especially to businesses. He is currently seeking a master's degree in economics from the University of Montana and his research focuses on the economics of gender empowerment in the developing world. During his professional life, he has worn many hats – from cashier, to barista, to community organizer. He feels that Montana offers a unique business environment that is often best understood by local businesses. He started his company, Duplovici, with his friends in an effort to meet the unique needs of Montana businesses, non-profits, and individuals. He believes technology is not simply an answer to profit maximization for businesses: by using internet technologies we can unleash human creativity through collective action and the arts, as well as business ventures. He is also the proud father of two girls and has a special place in his heart for getting girls involved with technology and business.
Read more
  • 0
  • 1
  • 7343

article-image-angularjs-love-affair-decade
Richard Gall
05 Feb 2016
6 min read
Save for later

AngularJS: The Love Affair of the Decade

Richard Gall
05 Feb 2016
6 min read
AngularJS stands at the apex of the way we think about web development today. Even as we look ahead to Angular 2.0, the framework serves as a useful starting point for thinking about the formation of contemporary expectations about what a web developer actually does and the products and services they create. Notably (for me at least) Angular is closely tied up with Packt’s development over the past few years. It’s had an impact on our strategic focus, forcing us to think about our customers in new ways. Let’s think back to the world before AngularJS. This was back in the days when Backbone.js meant something, when Knockout was doing the rounds. As this article from October has it, AngularJS effectively took advantage of a world suffering from ‘Framework fatigue’. It’s as if there was a ‘framework bubble’, and it’s only when that bubble burst that the way forward becomes clearer. This was a period of experimentation and exploration; improvement and efficiency were paramount, but a symptom of this was the way in which trends – some might say fads – took hold of the collective imagination. This period was a ‘framework’ bubble which, I’d suggest, prefigures the startup bubble, a period in which we’re living today. Developers were looking for new ways of doing things; they wanted to be more efficient, their projects more scalable, fast, and robust. All those words that are attached to development (in both senses of the word) took on particular urgency. As you might expect, this unbelievable pace of growth and change was like catnip for Packt. This insatiable desire for new tools was something that we could tapped into, delivering information and learning materials on even the most niche new tools. It was exciting. But it couldn’t last. It was thanks to AngularJS that this changed. Ironically, if AngularJS burst the framework bubble, ending what seemed like an endless stream of potential topics to cover, it also supplied us with some of our most popular titles. AngularJS Web Application Development Cookbook, for example, was a huge success. Written by Matt Frisbie, it helped us to forge a stronger relationship with the AngularJS world. It was weird – its success also brought an end to a very exciting period of growth, where Packt was able to reach out to new customers, small communities that other publishers could not. But we had to grow up. AngularJS was like a friend’s wedding; it made us realise that we needed to become more mature, more stable. But why, we should ask, was AngularJS so popular? Everyone is likely to have their own different story, their own experience of adopting AngularJS, and that, perhaps, is precisely the point. Brian Rinaldi, in the piece to which I refer above, notes a couple of things that made Angular a framework to which people could commit. Its ties with Google, for example gave it a mark of authority and reliability, while its ability to integrate with other frameworks means developers still have the flexibility to use the tools they want to while still having a single place to which they could return. Brian writes: The point is, all these integrations not only made the choice of Angular easier, but make leaving harder. It’s no longer just about the code I write, but Angular is tied into my entire development experience. Experience is fundamental here. If the framework bubble was all about different ways of doing the same thing faster and more effectively, today the reverse is true. Developers want to work in one way, but to be able to do lots of things. It’s a change in priorities; the focus of the modern web developer in 2016 has changed. The challenges are different, as mobile devices, SPAs, cloud, personalization, have become fundamental issues for web developers to reckon with. Good web developers looks beyond the immediacy of their project, and need to think carefully about users and about how they can deliver a great product or service. That’s what we’ve found at Packt. The challenges faced by the customers we serve are no longer quite so transparent or simple. If, just a few years ago, we relied upon the simple need to access information about a new framework, today the situation is more nuanced. Many of the challenges are due to changing user behaviour, a fragmentation of needs and contexts. For example, maybe you want to learn responsive web design? Or need to build a mobile app? Of course, these problems haven’t just appeared in the last 12 months, but they are no longer additional extras, but central to success. It’s these problems that have had a part in causing the startup bubble – businesses solving (or, if they’re really good, disrupting) customer needs with software. A framework such as React might be seen as challenging AngularJS. But despite its dedicated, almost evangelical core of support, it’s nevertheless relatively small. And it would also be wrong to see the emergence of React (alongside other tools, including Meteor), as a return to the heady days of the framework bubble. Instead it has grown out of a world inculcated by Angular – it is, remember, a tool designed to build a very specific type of application. The virtual DOM, after all, is an innovation that helps deliver a truly immediate and fast user experience. The very thing that makes React great is why it won’t supplant Angular – why would it even want to? If you do one thing, and do it well, you’re adding value that people couldn’t get from anywhere else. Fear of obsolescence – that’s the world in which AngularJS entered, and the world in which Packt grew. But today, the greatest fear isn’t so much obsolescence, it’s ‘Am I doing the right thing for my users? Are my customers going to like this website – this new app?’ So, as we await Angular 2.0, don’t forget what AngularJS does for you – don’t forget the development experience and don’t forget to think about your users. Packt will be ready when you want to learn 2.0 – but we’ll also still have the insights and guidance you need to do something new with AngularJS. Progress and development isn’t linear; it’s never a straight line. So don’t be scared to explore, rediscover what works. It’s not always about what’s new, it’s about what’s right for you. Save up to 70% on some of our very best web development titles from 11th to 17th April. From Flask to React to Angular 2, it's the perfect opportunity to push your web development skills forward. Find them here.
Read more
  • 0
  • 0
  • 1451
Unlock access to the largest independent learning library in Tech for FREE!
Get unlimited access to 7500+ expert-authored eBooks and video courses covering every tech area you can think of.
Renews at $19.99/month. Cancel anytime
article-image-angular-2-new-world-web-dev
Owen Roberts
04 Feb 2016
5 min read
Save for later

Angular 2 in the new world of web dev

Owen Roberts
04 Feb 2016
5 min read
This week at Packt we’re all about Angular, and with the release of Angular 2 just on the horizon there’s no better time to be an Angular user. Our first book on Angular was Mastering Web Application Development with AngularJS back in 2013 and it’s amazing to see how much the JS landscape is a completely different place than what it was just 3 or 4 years ago. How so? Well, Backbone was expected to lord over other frameworks as The Top Dog, while others like Ember and Knockout were carving their own respectable niches and fans. When Angular started to pick up steam it was seen as a breath of fresh air thanks to its simplicity and host of features. Compared to the more niche driven frameworks at the time the appeal of the Google lead powerhouse drove developers all over to give it a go, and managed to keep them hooked. Of course web dev is a different world than it was in 2013. We’ve seen the growth of full-stack JS development, JS promises are starting to become more in use, components are the latest step in building web apps, and a host of new frameworks and libraries have burst onto the scene as older ones begin to fade into the background. Libraries like React and Polymer are fantastic alternatives to frameworks for developers who want to pick and choose the best stuff for their apps; while Ember has gone from strength to strength in the last few years with a diehard fanbase. A different world means that rewriting Angular from the ground for 2.0 makes sense, but it’s not without its risks too. So, what does Angular need to avoid falling behind? Here are a few ideas (And hopes!) Ease-of-use One of Angular’s greatest strengths was how easy it was to use; not just in the actual coding, but also in integration. Angular has always had that bonus over the competition – one of the biggest reasons it became so popular was because so many other projects allowed for easy Angular integration. However, the other side of the coin was Angular’s equally difficult learning curve; before the book and tutorials found their way onto the market everyone was trying to find as much as they could about Angular in order to get the most out of the more complex or difficult parts of the framework. With 2.x being a complete rewrite every developer is back in the same place again, what the Angular team needs to ensure is that Angular is just as welcoming as its new competition - React, Ember, and even Polymer offer a host of ways to get into their development mindsets. Angular needs to do the same. Debugging Does anyone actually like debugging? My current attempts at Python usually grind to a halt when I reach the debugging phase and for a lot of developers there’s always that whisper of “Urgh” under their breath when they finally get around to bugs. Angular isn’t any different, and you can find a lot of articles and Stack Overflow questions all about debugging in Angular. For what it’s worth Angular seem to have learnt from their experiences with 1.x. They’ve worked directly with the team at Rangle.io to create Batarangle, which is a Chrome plugin that checks Angular 2 apps. Only time will tell how well debugging in Angular will work for every developer, but this is the sort of thing that the Angular team need to give developers – work with other teams to build better tools that help developers breeze through the more difficult tasks. The future devs vs the old With the release of Angular 2 in the coming months we’re going to see React and Angular 2 fight for dominance as the defacto framework on the JS market. The rewrite of Angular is arguably the biggest weakness and strength that Angular 2 offers. For previous Angular 1.x users there are two routes you can go down: Take the jump to Angular 2 and learn everything again. Decide the clean slate is an opportunity to give React a try – maybe even stick with it. What does Angular need to do to ensure after the release of 2 to get old users back on the Angular horse? A few of the writers that I’ve worked with in the past have talked about Angular as the Lego of the JS world – it’s simpler to pick up and everything fits snug together. There’s a great simplicity in building good looking Angular apps – the team needs to remind more jaded Angular 1.x fans that 2.x is the same Angular they love rebuilt for the new challenges of 2016 onwards. It’s still fun Lego, but shinier. If you’re new to the framework and want to see why it’s become such a beloved framework then be sure to check out our Angular tech page; this page has all our best eBooks and videos, as well as the chance to preorder our upcoming Angular 2 titles to download the chapters as soon as they’re finished.
Read more
  • 0
  • 0
  • 1714

article-image-angularjs-2-the-tempest-we-should-all-embrace
Ed Gordon
19 Nov 2015
5 min read
Save for later

AngularJS 2.0 is a tempest we should all embrace

Ed Gordon
19 Nov 2015
5 min read
2016 will be the year of AngularJS 2.0 and it’s going to be awesome. AngularJS has been a known quantity to Packt for about 4 years, and has been around for 6. In the last 24 months, we’ve really seen it gain massive adoption amongst our user base. Conferences are held in its name. It will come as no surprise that it’s one of our best-selling topics. Thousands of apps have been deployed and created with it. People, do in fact, love it. So the decision to rewrite the entire project seems odd. A lot has been written about this already from developers who know their stuff. Some are for it, some against it, and some are a little more balanced. For a technically reasoned article, Rob Eisenberg’s blog about AngularJS 2.0 is the best of many I’ve read. For one that quotes Shakespeare, read on. At Packt I’ve been the commissioning editor on a fair number of products. You may remember me from such hits as MEAN Web Development and Mastering D3.js. While I may not have the developer nous, creating a product is the same process whether it is a good framework or a good book. And part of this process understanding when you’ve got a good product, and when you had a good product that needs ripping up, and starting over. What’s past is prologue AngularJS’s design was emergent from increased adoption. It started life as a tool to aid designers throw up a quick online form. It was an internal tool at Google. They didn’t realise that every Joe Web Developer would be using it to power their client’s not-so-SEO-friendly bespoke applications. It’s the equivalent of what would happen if people started using this blog as a template for all future blogs. I’d enjoy it for the first few years, living the blogosphere high-life, then people would start moaning to me, and I would hate it. I’d have to start again, for my own health as much as for the health of the millions of bloggers who were using my formatting to try and contain their vastness. So we’re agreed that they need to change things. Good. Oh brave new world/That has such features in’t Many frameworks change things whilst maintaining backwards compatibility. WordPress is a famous example of doing everything possible to avoid introducing breaking-changes at any major update. The result is, by now, a pretty bloated application that much like Angular, started out serving a very different purpose to how it now finds itself being deployed. It’s what gave rise to smaller, lighter-weight platforms like Ghost, designed purely for blogging. AngularJS however is not an example of developers maintaining backwards compatibility. It takes pleasure in starting over. In fact, you can just about rip up your old Angular apps now. It’s for your own good. By starting from a clean slate, the Angular team have the chance to design AngularJS in to what it should be rather than what it ended up being. It may not make sense to the developers who are using Angular 1.x at the moment, but to be frank Google doesn’t care. It cares about good products. It’s planning a product that will endeavour to remain relevant in to the future, rather than spending its time trying to patch up something that was a result of rushed 2010 thinking. Part of this attempt at continued relevance is TypeScript. TypeScript extends the capabilities of ES6; moving to AngularJS 2.0 before ES7 is released means that it’s recommended that TypeScript is used to make the most of what Angular offers. This is a big move, but it’s an attempt at moving the capabilities forward. Doing something is always preferable to doing nothing. The other headline act, and related to the ES6 features is the move to make Angular compatible with Web Components. Web Components will redefine what web development means, in time, and making sure that their framework is on hand to help deliver them safely to developers is again a smart product decision. The temporary pain of the rewrite will be rewarded by increased ease of use and longevity for the developers and clients who build and consume AngularJS applications. There are a whole host more features; a move to mobile-first design, which I understand, and lots of technical and syntax improvements, which I don’t; increased performance, and plenty more too. Every decision is being made to make Angular a better product for everyone who uses it. Gentle breath of yours my sails/Must fill, or else my project fails AngularJS 2.0 has been a divisive figure in the web development world. I’ve been at Packt for three years and can’t remember a time when such a popular and well-used technology completely ripped up everything they had and started again. It will set a precedent in software that will shape the future, either way it ‘goes down’. What we should focus on is that this wholesale change is designed to make the product better – not just now, but in to the future - and that decision should be applauded. It’s not unheard of for Google to stop/start/abandon high-profile projects (cough Google Glass cough), but they should be recognised nonetheless for their dedication in trying to make this a more accessible and useful platform long term. Ultimately though, it will be the users who decide if they won or lost. The team are bringing a different project in the hope that people see its advantages, but no matter the intent a product is only useful if the consumers find it useful. Through our ‘gentle breath’, the Angular project will fly or fail. Let’s embrace it.
Read more
  • 0
  • 0
  • 1942

article-image-one-second-website-10x-your-site-performance
Dave Barnes
20 Oct 2015
5 min read
Save for later

The One Second Website : 10x your site performance

Dave Barnes
20 Oct 2015
5 min read
Last year, Patrick Hamann gave a talk for Google Developers on Breaking News at 1000ms. It lays out how Patrick and his team built a 1-second web site for the Guardian, improving performance almost 10 times. I learned a lot from the talk, and I’ve summarized that below. Here’s the video: And you can browse the slides here: Web speed has come to a head recently. Facebook’s Instant Articles put speed on everyone’s radar. A news page takes 8 seconds to load, and that puts people off clicking links. Like many others, I couldn’t quite believe things had got this bad. We have fast broadband and wifi. How can a 1,000 word article take so long? So there’s a lot of discussion around the problem, but Patrick’s talk lays out many of the solutions. Here’s the keys I took from it: The problem Sites are slow, really slow. 8 seconds is normal. And yet, people really care about speed. It’s a user’s second most important feature, right after “easy to find content”. In fact, if it takes more than a second for a page to respond people start to assume the site is broken. If most pages take more than a second, people start to assume the web is broken. And we wonder why 91% of mobile impressions are in apps, not the web. The budget Patrick set a hard budget for page loads of 1 second, and measured everything against that. This is his BHAG — make the web site nearly 10x faster. But once the goal is clear, people have a habit of finding solutions. The harder the goal, the more radical the solutions people will find. Modest goals lead to modest problem solving. Next time you want to improve something, set a 10x goal, get serious about it — and let everybody’s ingenuity loose on the solution. The solution Patrick and his team’s radical solutions revolved around 4 key principles. Deliver core content first There’s a lot of stuff on a news article page, but what we really want to see is the article content. Patrick’s team got serious about the really important stuff, creating a ‘swim lane’ system. The important stuff — the core article content — was put into a fast lane, loaded first, and then the rest built around it. This made the goal more doable. The whole page didn’t need to load in 1000ms. If the core content loaded in 1s people could read it, and by the time they had the rest of the page would be ready. (Even the flimsiest Guardian article will take more than 1s to read!.) Core content should render within 1000ms Here’s the problem. To get content to the reader in 1000ms you have only 400ms to play with, because the basic network overhead takes 600ms over a good 3g connection. So to really supercharge speed, the Guardian inlined the critical CSS. For the Guardian, the critical CSS is the article formatting. The rest can come a bit later. The new site uses JavaScript to download, store, and load CSS on demand rather than leaving that decision to the browser.  From: https://speakerdeck.com/patrickhamann/breaking-news-at-1000ms-front-trends-2014 Every feature must fail gracefully Fonts are a recognizable part of the Guardian brand, important despite the overhead. But not that important. The new design fails decisively and fast when it’s right to do so: Decision tree — fallback vs. custom font. The really clever bit of the whole set up is the font JSON. Instead of downloading several font binaries, just one JSON request downloads all the fonts in base64 encoding. This means some overhead in file size, but replaces several requests with just one cachable object: A nice trick, and one you can use yourself: they made webfontjson an Open Source project. Every request should be measured The final pillar really comes down to really knowing your shit. Graph and measure EVERYTHING that affects your performance and your time-to-render budget. In addition to the internal analytics platform Opan, Patrick uses Speedcurve to monitor and report on performance against a set of benchmarks over time: Sum up For everyone… big improvements come from BIG GOALS and ingenious solutions. Be ambitious and set a budget/goal that gives great customer benefit, then work towards it. For web developers: Performance is a requirement. Everybody has to have it as a priority from day one. Take the one second web site challenge. Make that your budget, and measure, optimize, repeat. Make the core content download first, render it in the fast lane. Then build the rest around the outside. Now if that whet your appetite, watch the video. Especially if you’re more involved in web dev, I’m sure you’ll learn a lot more from it than I did! What techniques do you use to 10x your site’s performance? From 11th to 17th April save up to 70% on some of our very best web development products. It's the perfect opportunity to explore - and learn - the tools and frameworks that can help you unlock greater performance and build even better user experiences. Find them here.
Read more
  • 0
  • 0
  • 1374

article-image-intro-meteor-js-full-stack-developers
Ken Lee
14 Oct 2015
9 min read
Save for later

Intro to Meteor for JS full-stack developers

Ken Lee
14 Oct 2015
9 min read
If you are like me, a JavaScript full-stack developer, your choices of technology might be limited when dealing with modern app/webapp development. You could choose a MEAN stack (MongoDB, Express, AngularJS, and Node.js), learn all four of these technologies in order to mix and match, or employ some ready frameworks, like DerbyJS. However , none of them provide you with the one-stop shop experience like Meteor, which stands out among the few on the canvas. What is Meteor? Meteor is an open-source "platform" (more than a framework) in pure JavaScript that is built on top of Node.js, facilitating via DDP protocol and leveraging MongoDB as data storage. It provides developers with the power to build a modern app/webapp that is equipped with production-ready, real-time (reactive), and cross-platform (web, iOS, Android) capabilities. It was designed to be easy to learn, even for beginners, so we could focus on developing business logic and user experience, rather than getting bogged down with the nitty-gritty of learning technologies' learning curve. Your First Real-time App: Vote Me Up! Below, we will be looking at how to build one reactive app with Meteor within 30 mins or less. Step 1: Installation (3-5 Mins) For OS X or Linux developers, head over to the terminal and install the official release from Meteor. $ curl https://install.meteor.com/ |sh For Windows developers, please download the official installer here. Step 2: Create an app (3-5 mins) After we have Meteor installed, we now can create new app simply by: $ meteor create voteMeUp This will create a new folder named voteMeUp under the current working directory. Check under the voteMeUp folder -- we will see that three files and one folder have been created. voteMeUp/ .meteor/ voteMeUp.html voteMeUp.css .meteor is for internal use. We should not touch this folder. The other three files are obvious enough even for beginners -- the HTML markup, stylesheet, and one JavaScript that made the barebone structure one can get for web/webapp development. The default app structure tells us that Meteor gives us freedom on folder structure. We can organise any files/folders we feel appropriate as long as we don't step onto the special folder names Meteor is looking at. Here, we will be using a basic folder structure for our app. You can visit the official documentation for more info on folder structure and file load order. voteMeUp/ .meteor/ client/ votes/ vote.html vote.js main.html collections/ votes.js server/ presets.js publications.js Meteor is a client-database-server platform. We will be writing codes for client and server independently, communicating through the reactive DB drivers API, publications, and subscriptions. For a brief tutorial, we just need to pay attention to the behaviour of these folders Files in client/ folder will run on client side (user browser) Files in server/ folder will run on server side (Node.js server) Any other folders, i.e. collections/ would be run on both client and server Step 3: Add some packages (< 3 mins) Meteor is driven by an active community, since developers around the world are creating reusable packages to compensate app/webapp development. This is also why Meteor is well-known for rapid prototyping. For brevity’s sake, we will be using packages from Meteor: underscore. Underscore is a JavaScript library that provides us some useful helper functions, and this package provided by Meteor is a subset of the original library. $ meteor add underscore There are a lot useful packages around; some are well maintained and documented. They are developed by seasoned web developers around the world. Check them out: Iron Router/Flow Router, used for application routing Collection2, used for automatic validation on insert and update operations Kadira, a monitoring platform for your app Twitter Bootstrap, a popular frontend framework by Twitter Step 3: Start the server (< 1 min) Start the server simply by: $ meteor Now we can visit site http://localhost:3000. Of course you will be staring at a blank screen! We haven't written any code yet. Let's do that next. Step 4: Write some code (< 20 Mins) As you start to write the first line of code, by the time you save the file, you will notice that the browser page will auto reload by itself. Thanks to the hot code push mechanism built-in, we don't need to refresh the page manually. Database Collections Let's start with the database collection(s). We will keep our app simple, since we just need one collection, votes, that we will put it in collections/votes.js like this: Votes = newMongo.Collection('votes'); All files in the collections/ folder run on both the client and the server side. When this line of code is executed, a mongo collection will be established on the server side. On the client side, a minimongo collection will be established. The purpose of the minimongo is to reimplement the MongoDB API against an in-memory JavaScript database. It is like a MongoDB emulator that runs inside our client browser. Some preset data We will need some data to start working with. We can put this in server/presets.js. These are just some random names, with vote count 0 to start with. if (Votes.find().count() === 0) { Votes.insert({ name: "Janina Franny", voteCount: 0 }); Votes.insert({ name: "Leigh Borivoi", voteCount: 0 }); Votes.insert({ name: "Amon Shukri", voteCount: 0 }); Votes.insert({ name: "Dareios Steponas", voteCount: 0 }); Votes.insert({ name: "Franco Karl", voteCount: 0 }); } Publications Since this is for an educational purpose, , we will publish (Meteor.publish()) all the data to the client side under server/publications.js. You most likely would not do this for a production application. Planning for publication is one major step in Meteor app/webapp development, so we don't want to publish too little or too much data over to client. Just enough data is what we always keep an eye out for. Meteor.publish('allVotes', function() { return Votes.find(); }); Subscriptions Once we have the publication in place, we can start to subscribe to them by the name, allVotes, as shown above in the publication. Meteor provides template level subscription, which means we could subscribe to the publication when a template is loaded, and get unsubscribed when the template is destroyed. We will be putting in our subscription under client/votes/votes.js, (Meteor.subscribe()). onCreated is a callback when the template name votes is being created. Template.votes.onCreated(function() { Meteor.subscribe('allVotes'); }); The votes template put in client/votes/votes.html would be some simple markup such as the following: <template name="votes"> <h2>All Votes</h2> <ul> {{#each sortedVotes}} <li>{{name}} ({{voteCount}}) <button class="btn-up-vote">Up Vote</button></li> {{/each}} </ul> <h3>Total votes: {{totalVotes}}</h3> </template> If you are curious what those markups are with {{ and }}, enter Meteor Blaze, which is a powerful library for creating live-updating on client side. Similar to AngularJS and React, Blaze serves as the default front-end templating engine for Meteor, but it is simpler to use and easier to understand. The Main Template There must be somewhere to start our application. client/main.html is the place to kickoff our template(s). <body> {{> votes}} </body> Helpers In order to show all of our votes we will need some helper functions. As you can see from the previous template, {{#each sortedVotes}}, where a loop should happen and print out the names and their votes in sorting order {{totalVotes}}, which is supposed to show the total vote count. We will put this code into the same file we have previously worked on: client/votes/votes.js, and the complete code should be: Template.votes.onCreated(function() { Meteor.subscribe('allVotes'); }); Template.votes.helpers({ 'sortedVotes': function() { return Votes.find({}, { sort: { voteCount: -1 } }) }, 'totalVotes': function() { var votes = Votes.find(); if (votes.count() > 0) { return _.reduce(votes.fetch(), function(memo, obj) { return memo + obj.voteCount; }, 0); } } }); Sure enough, the helpers will return all of the votes, sorted in descending order (the larger number on top), and returning the sum (reduce - function provided by underscrore) of votes. This is all we need to show the vote listing. Head over to the browser, and you should be seeing the listing on-screen! Events In order to make the app useful and reactive we need an event to update the listing on the fly when someone votes on the names. This can be done easily with an event binding to the 'Up Vote' button. We will be adding the event handler in the same file: client/votes/votes.js Template.votes.onCreated(function() { Meteor.subscribe('allVotes'); }); Template.votes.helpers({ 'sortedVotes': function() { return Votes.find({}, { sort: { voteCount: -1 } }) }, 'totalVotes': function() { var votes = Votes.find(); if (votes.count() > 0) { return _.reduce(votes.fetch(), function(memo, obj) { return memo + obj.voteCount; }, 0); } } }); Template.votes.events({ 'click .btn-up-vote': function() { Votes.update({ _id: this._id }, { $inc: { voteCount: 1 } }); } }); This new event handler just did a quick and dirty update on the Votes collections, by field name _id. Each event handler will have this pointing to the current template context -- i.e. the {{#each}} in the template indicates a new context. So this._id will return the current _id of each record in the collection. Step 5: Done. Enjoy your first real-time app! You can now visit the site with different browsers/tabs open side by side. Action on one will trigger the reactive behavior on the other. Have fun voting! Conclusion By now, we can see how easily we can build a fully functional real-time app/webapp using Meteor. With "great power comes great responsibility[RJ8] " (pun intended), and proper planning/structuring for our app/webapp is of the utmost importance once we have empowered by these technologies. Use it wisely and you can improve both the quality and performance of your app/webapp. Try it out, and let me know if you are sold. Resources: Meteor official site Meteor official documentation Meteor package library: Atmosphere Discover Meteor Want more JavaScript content? Look no further than our dedicated JavaScript page.  About the Author Ken Lee is the co-found of Innomonster Pte. Ltd. (http://innomonster.com/), a specialized website/app design & development company based in Singapore. He has eight years of experience in web development, and is passionate about front-end and JS full-stack development. You can reach him at ken@innomonster.com.
Read more
  • 0
  • 0
  • 3312
article-image-guide-better-typography-web
Brian Hough
19 Aug 2015
8 min read
Save for later

Better Typography for the Web

Brian Hough
19 Aug 2015
8 min read
Despite living in a world dominated by streaming video and visual social networks, the web is still primarily a place for reading. This means there is a tremendous amount of value in having solid, readable typography on your site. With the advances in CSS over the past few years, we are finally able to tackle a variety of typographical issues that print has long solved. In addition, we are also able to address a lot of challenges that are unique to the web. Never have we had more control over web typography. Here are 6 quick snippets that can take yours to the next level. Responsive Font Sizing Not every screen is created equal. With a vast array of screen sizes, resolutions, and pixel densities it is crucial that our typography adjusts itself to fit the user's screen. While we've had access to relative font measurements for awhile, they have been cumbersome to work with. Now with rem we can have relative font-sizing without all the headaches. Let's take a look at how easy it is to scale typography for different screens. html { font-size: 62.5%; } h1 { font-size: 2.1rem // Equals 21px; p { font-size: 1.6rem; // Equals 16px } By setting font-size to 62.5% it allows use base 10 for setting our font-size using rem. This means a font set to 1.6rem is the same as setting it to 16px. This makes it easy to tell what size our text is actually going to be, something that is often an issue when using em. Browser support for rem is really good at this stage, so you shouldn't need a fallback. However, if you need to support older IE it is simple as creating a second font-size rule set in px after the line you set it in rem. All that is left is to scale our text based on screen size or resolution. By using media queries, we can keep the relative sizing of type elements the same without having to manually adjust each element for every breakpoint. // Scale Font Based On Screen Resolution @media only screen and (min-device-pixel-ratio: 2), only screen and (min-resolution: 192dpi) { html { font-size: 125%; } } // Scale Font Based On Screen Size @media only screen and (max-device-width : 667px) { html { font-size: 31.25%; } } This will scale all the type on the page with just one property per breakpoint, there is now no excuse not to adjust font-size based on your users' screens. Relative Line Height Leading, or the space between baselines in a paragraph, is an important typographical attribute that directly affects the readability of your content. The right line height provides a distinction between lines of text, allowing a reader to scan a block of testing quickly. An easy tip a lot of us miss is setting a unitless line-height. By setting line-height in this way, it acts as a ratio to the size of your type. This scales your leading with your font-size, making it a perfect compliment to using rem: p { font-size: 1.6rem; line-height: 1.4; } This will set our line-height at a ratio of 1.4 times our font-size. Consequently, 1.4 is a good value to start with when tweaking your leading, but your ratio will ultimately depend on the font you are using. Rendering Control The way type renders on a web page is affected not only by the properties of a user's screen, but also by their operating system and browser. Different font-rendering implementations can mean the difference between your web fonts loading quickly and clearly or chugging along and rendering into a pixelated mess. Font services like TypeKit recognize this problem and provide you a way to preview how a font will appear in different operating system/browser combinations. Luckily though, you don't have to leave it completely up to chance. Some browser engines, like WebKit, give us some extra control over how a font renders. text-rendering controls how a font is rendered by the browser. If your goal is optimal legibility, setting text-rendering to optimizeLegibility will make use of additional information provided in certain fonts to enhance kerning and make use of built-in ligatures. p.legibility { text-rendering: optimizeLegibility; } While this sounds perfect, there are scenarios where you don't want to use it. It can crush rendering times on less powerful machines, especially mobile browsers. It is best to use it sparingly on your content, and not just apply to every piece of text on a page. All browsers support this property except Internet Explorer. This is not the only way you can optimize font rendering. Webkit browsers also allow you to adjust the type of anti-aliasing they use to render fonts. Chrome is notoriously polarizing in how fonts look, so this is a welcome addition. It is best to experiment with the different options, as it really comes down to the font you've chosen and your personal taste. p { webkit-font-smoothing: none; webkit-font-smoothing: antialiased; webkit-font-smoothing: subpixel-antialiased; } Lastly, if you don't find that the font-smoothing options aren't enough, you can had a bit of boldness to your fonts in WebKit, with the following snippet. The result isn't for everyone, but if you find your font is rendering a bit on the light side, it does the trick. p { -webkit-text-stroke 0.35px; } Hanging Punctuation Hanging punctuation is a typographical technique that keeps punctuation at the begging of a paragraph from disrupting the flow of the text. By utilizing the left margin, punctuation like open quotes and list bullets are able to be displayed while still allowing text to be left justified. This makes it easier for the reader to scan a paragraph. We can achieve this effect by applying the following snippet to elements where we lead with punctuation or bullets. p:first-child { text-indent: -0.5rem; } ul { padding: 0px; } ul li { list-style-position: outside; } One note with bulleted lists is to make sure its container does not have overflow set to hidden as this will hide the bullets when they are set to outside if you want to be super forward-looking. Work is being done on giving us even more control over hanging punctuation, including character detection and support for leading and trailing punctuation. Proper Hyphenation One of the most frustrating things on the web for typography purists is the ragged right edge on blocks of text. Books solve this through carefully justified text. This, unfortunately, is not an option for us yet on the web, and while a lot of libraries attempt to solve this with JavaScript, there are some things you can do to handle this with CSS alone. .hyphenation { -ms-word-break: break-all; word-break: break-all; // Non standard for webkit word-break: break-word; -webkit-hyphens: auto; -moz-hyphens: auto; hyphens: auto; } .no-hyphenation { -ms-word-break: none; word-break: none; // Non standard for webkit word-break: none; -webkit-hyphens: none; -moz-hyphens: none; hyphens: none; } Browser support is pretty solid, with Chrome being the notable exception. You must set a language attribute on the parent element, as the browser leverages this to determine hyphenation rules. Also, note if you are using Autoprefixer, it will not add all the appropriate variations to the hyphens property. Descender-Aware Underlining This is a newer trick I first noticed in iMessage on iOS. It makes underlined text a bit more readable by protecting descenders (the parts of a letter that drop before the baseline) from being obscured by the underline. This makes it an especially good fit for links. .underline { text-decoration: none; text-shadow: .03rem 0 #FFFFFF,-.03rem 0 #FFFFFF,0 .03rem #FFFFFF,0 -.03rem #FFFFFF,.06rem 0 #FFFFFF,-.06rem 0 #FFFFFF,.09rem 0 #FFFFFF,-.09rem 0 #FFFFFF; color: #000000; background-image: linear-gradient(#FFFFFF,#FFFFFF),linear-gradient(#FFFFFF,#FFFFFF),linear-gradient(#000000,#000000); background-size: .05rem 1px,.05rem 1px,1px 1px; background-repeat: no-repeat,no-repeat,repeat-x; background-position: 0 90%,100% 90%,0 90%; } First, we create a text-shadow the same color as our background (in this case white) around the content we want to be underlined. The key is that the shadow is thin enough to obscure things behind it, without overlapping other letters. Next, we use a background gradient to recreate our underline. The text shadow alone is not enough as a normal text-decoration: underline is actually placed over the type. The gradient will appear just like a normal underline, but now the text-shadow will obscure the underline where the descenders overlap it. By using rem, this effect also scales based on our font-size. Conclusion Users still spend a tremendous amount of time reading online. Making that as frictionless as possible should be one of the top priorities for any site with written content. With just a little bit of CSS, we can drastically improve the readability of our content with little to no overhead. About The Author Brian is a Front-End Architect, Designer, and Product Manager at Piqora. By day, he is working to prove that the days of bad Enterprise User Experiences are a thing of the past. By night, he obsesses about ways to bring designers and developers together using technology. He blogs about his early stage startup experience at lostinpixelation.com, or you can read his general musings on twitter @b_hough.
Read more
  • 0
  • 0
  • 1782

article-image-devops-engineering-and-full-stack-development
Richard Gall
28 Jul 2015
5 min read
Save for later

DevOps engineering and full-stack development – 2 sides of the same agile coin

Richard Gall
28 Jul 2015
5 min read
Two of the most talked-about and on-trend roles in tech dominated our Skill Up survey – DevOps engineers and Full-Stack developers. Even before we started exploring our data, we knew that both would feature heavily. Given the amount of time spent online arguing about DevOps and the merits and drawbacks of full-stack development, it’s interesting to see exactly what it means to be a DevOps engineer or full-stack developer. From salary to tool use, both our Web Development and SysAdmin and Security Salary and Skills Reports offer an insight into the professional lives of people actually performing these roles every day. The similarities between DevOps engineering and full-stack development The similarities between the two roles are striking. Both DevOps engineering and full-stack development are having a considerable impact on the way in which technology is used and understood within organizations and businesses – which makes them particularly valuable. In SMEs, for example, DevOps engineers command almost the same amount of money as in Enterprise. Considering the current economic climate, it’s a clear signal of the value of DevOps practices in environments where flexibility and the ability to adapt to changing demands and expectations are crucial to growth. Full-stack developers also command the highest salaries in many industries. In consultancy, for example, full-stack developers earn significantly more than any other web development role. While this could suggest that organizations aren’t yet willing to invest in (or simply don’t need) in-house full-stack developers, it highlights that they are nevertheless willing to spend money on individuals with full-stack knowledge, who are capable of delivering cutting-edge insight. However, just as we saw Cloud consultancies dominate the tech consultancy market a few years ago, over time it’s likely that full-stack development will become more and more established as a standard. DevOps engineers and full-stack developers share the same philosophical germ. They are symptoms of a growing business demand for greater agility and flexibility, and hint at a trend towards greater generalization in the skillset of technical professionals. part of the thrill of #devops to me is how there's no true agreement about what it is. it's like watching LOST all over again — jon devops hendren (@devops) May 18, 2015 Full-stack developers are using DevOps tools I’ve always seen them as manifestations of similar ideas in different technical areas. However, when you look at the data we’ve collected in our survey, alongside some wider research, the relationship between the DevOps engineer and the Full-Stack developer might possibly be more than purely conceptual. ‘Full-Stack’ and ‘DevOps’ are both terms that blur the lines between developer and engineer, and both are two sides of an intriguing form of cross-pollination; technologies more commonly used for deployment and automation. Docker and Vagrant were the most notable, highlighting the impact of containerization and virtualization on web development, but we also found a number of references to the Microsoft automation tool PowerShell – a distinctly DevOps-esque tool if ever there was one. Perhaps there’s a danger of overstating my point – surely we shouldn’t be surprised if web developers are using these tools – it’s not that strange, right? Maybe, but the fact that tools such as these are being used by web developers in their day-to-day work suggests that they are no longer simply expected to develop: they also need to deploy and configure their projects. Indeed, it’s worth noting that across all our web development respondents, a large number plan on learning Docker over the next 12 months. DevOps engineers use a huge range of tools DevOps Engineers were even more eclectic in their tool-usage than full-stack developers. Python is the language of-choice and Puppet the go-to configuration management tool, but web tools such as JavaScript and PHP are also being used. References to Flask, for example, the Python microframework, emphasise the way in which DevOps Engineers have an eye on web development while they’re automating your infrastructure. Taken alone, these responses might not fully evidence the relationship between DevOps engineers and Full-Stack developers. However, there are jobs out there asking for a combination of both skillsets. One, posted by a recruiter working for a nameless ‘creative media house’ in London, was looking for someone to become ‘a key member of multi-party cloud research projects, helping to bring a microservices-based video automation system to life, integrate development and developed systems into onside and global infrastructure’. The tools being asked for were very varied indeed. From a high-level language, such as JavaScript, to scripting languages such as Bash, Python and Perl, to continuous integration tools, configuration management tools and containerization technologies, whoever eventually gets the job certainly deserves to be called a polyglot. Blurring the line between full-stack and DevOps A further indication of the blurred line between engineers and developers can be found in this article from computing.co.uk. It’s an interesting tale of how working practices develop according to necessity and how methodologies and ideas interact with the practical details of a given situation. It tells the story of how the Washington Post went about building its submission platform, and how the way in which the project was resourced and managed changed according to certain pressures – internal and external. The title might actually be misleading – if you read it, it’s not so much that DevOps necessitates full-stack development, more that each thing grows out of the next. It might even be said that the reverse is true – that full-stack development necessitates DevOps thinking. The relationship between DevOps and full-stack development gives a real indication of the state of the tech world in 2015. Within a tech landscape of increasing complexity and cross-pollination there are going to be opportunities for developers and engineers to significantly drive their value as technical professionals. It’s simply a question of learning more, and of being open to new challenges and ideas about how to work effectively. It probably won’t be easy, but it might just be a fun journey.
Read more
  • 0
  • 0
  • 17601

article-image-biggest-web-developer-salary-and-skills-survey-2015
Packt Publishing
27 Jul 2015
1 min read
Save for later

The biggest web developer salary and skills survey of 2015

Packt Publishing
27 Jul 2015
1 min read
The following infographic is taken from our comprehensive Skill Up IT industry salary reports, with data from over 20,000 developers. Download the full size infographic here.    
Read more
  • 0
  • 0
  • 1637
article-image-today-you-are-not-web-developer-if-you-dont-know-javascript
Mario Casciaro
01 Jul 2015
6 min read
Save for later

You're not a web developer if you don't know JavaScript

Mario Casciaro
01 Jul 2015
6 min read
Mario Casciaro is a software engineer and technical lead with a passion for open source. After the recent publication of his successful book Node.JS Design Patterns, we caught up with him to discuss his views on today’s most important web development skills, and what the future holds. The best tool for the job may not be in your skillset yet I remember working on a small side project, something I try to do as much as possible, to put new skills into practice and try things outside of my job. It was a web application, something very similar to a social network, and I remember choosing Java with the Spring Framework as the main technology stack, and Backbone on the front-end. At the time - around 4 years ago - I was an expert Java developer, and considered it the technology with the most potential. It worked perfectly to implement enterprise web applications as well as mission-critical distributed applications and even mobile apps. While Java is still a popular and valuable tool in 2015, my experience doing this small side project made me rethink my opinion – I wouldn’t use it today unless there was a particular need for it. I remember that at some point I realized I was spending a lot of my development time in designing the object-oriented structure of the application and writing boilerplate code. Trying to find a solution, I migrated the project to Groovy and Grails and on the front-end I tried to implement a small homemade two-way binding framework. Things improved a little, but I was still feeling the need for something more agile on both ends, something more suited to the web. The web moves fast, so always let your skills evolve I wanted to try something radically different than the typical PHP, Ruby on Rails or Python for the server or JQuery or Backbone for the client. Fortunately I discovered Node.js and Angular.js, and that changed everything. By using Node I noticed that my mindset shifted from “how to do things” to “just get things done”. On the other hand, Angular revolutionized my approach to front end development, allowing me to drastically cut the amount of boilerplate code I was using. But most importantly, I realized that JavaScript and its ecosystem was becoming a seriously big thing. Today I would not even consider building a web application without having JavaScript as my primary player. The amount of packages on npm is staggering - a clear indication that the web has shifted towards JavaScript. The most impressive part of this story is that I also realized the importance that these new skills had in defining my career; if I wanted to build web applications, JavaScript and its amazing ecosystem had to be the focus of my learning efforts. This led me to find a job where Node, Angular and other cutting-edge JavaScript technologies actually played a crucial role in the success of the project I was in charge of creating. But the culmination of my renewed interest in JavaScript is the book I published 6 months ago - Node.jsDesignPatterns - which contains the best of the experience I accumulated since I devoted myself to the full-stack JavaScript mantra. The technologies and the skills that matter today for a web developer Today, if I had to give advice to someone approaching web development for the first time I would definitely recommend starting with JavaScript. I wouldn’t have said that 5-6 years ago, but today it’s the only language that allows you to get started both on the back end and the front end. Moreover JavaScript, in combination with other web technologies such as HTML and CSS, gives you access to an even broader set of applications with the help of projects like nw.js and ApacheCordova. PHP, Ruby, and Python are still very popular languages for developing the server-side of a web application, but for someone that already knows JavaScript, Node.js would be a natural choice. Not only does it save you the time it takes to learn a new language, it also offers a level of integration with the front end that is impossible with other platforms. I’m talking, of course, about sharing code between the server and the client and even implementing isomorphic applications which can run on both Node.js and the browser. React is probably the framework that offers the most interesting features in the area of isomorphic application development and definitely something worth digging into more, and it’s likely that we’ll also see a lot more from PouchDB, an isomorphic JavaScript database that will help developers build offline-enabled or even offline-first web applications more easily than ever before. Always stay ahead of the curve Today, as 4 years ago, the technologies that will play an important role in the web of tomorrow are already making an impact. WebRTC, for example, enables the creation of real-time peer-to-peer applications in the browser, without the need for any additional plugin. Developers are already using it to build fast and lightweight audio/video conferencing applications or even complete BitTorrent clients in the browser! Another revolutionizing technology is going to be ServiceWorkers which should dramatically improve the capabilities of offline applications. On the front end, WebComponents are going to play a huge role, and the Polymer project has already demonstrated what this new set of standards will be able to create. With regards to JavaScript itself, web developers will have to become familiar with the ES6 standard sooner than expected, as cross-compilation tools such as Babel are already allowing us to use ES6 on almost any platform. But we should also keep an eye on ES7 as it will contain very useful features to simplify asynchronous programming. Finally, as the browser becomes the runtime environment of the future, the recently revealed WebAssembly promises to give the web its own “bytecode”, allowing you to load code written in other languages from JavaScript, When WebAssembly becomes widely available, it will be common to see a complex 3D video game or a full-featured video editing tool running in the browser. JavaScript will probably remain the mainstream language for the web, but it will be complemented by the new possibilities introduced by WebAssembly. If you want to explore the JavaScript ecosystem in detail start with our dedicated JavaScript page. You'll find our latest and most popular, along with free tutorials and insights.
Read more
  • 0
  • 0
  • 3102

article-image-best-angular-yet-new-features-angularjs-13
Sebastian Müller
16 Apr 2015
5 min read
Save for later

The best Angular yet - New Features in AngularJS 1.3

Sebastian Müller
16 Apr 2015
5 min read
AngularJS 1.3 was released in October 2014 and it brings with it a lot of new and exciting features and performance improvements to the popular JavaScript framework. In this article, we will cover the new features and improvements that make AngularJS even more awesome. Better Form Handling with ng-model-options The ng-model-options directive added in version 1.3 allows you to define how model updates are done. You use this directive in combination with ng-model. Debounce for Delayed Model Updates In AngularJS 1.2, with every key press, the model value was updated. With version 1.3 and ng-model-options, you can define debounce time in milliseconds, which will delay the model update until the user hasn’t pressed a key in the configured time. This is mainly a performance feature to save $digest cycles that would normally occur after every key press when you don’t use ng-model-options: <input type="text" ng-model="my.username" ng-model-options="{ debounce: 500 }" /> updateOn - Update the Model on a Defined Event An alternative to the debounce option inside the ng-model-options directive is updateOn. This updates the model value when the given event name is triggered. This is also a useful feature for performance reasons. <input type="text" ng-model="my.username" ng-model-options="{ updateOn: 'blur' }" /> In our example, we only update the model value when the user leaves the form field. getterSetter - Use getter/setter Functions in ng-model app.js: angular.module('myApp', []).controller('MyController', ['$scope', function($scope) { var myEmail = 'example@example.com'; $scope.user = { email: function email(newEmail) { if (angular.isDefined(newEmail)) { myEmail = newEmail; } return myEmail; } }; }]); index.html: <div ng-app="myApp" ng-controller="MyController"> current user email: {{ user.email() }} <input type="email" ng-model="user.email" ng-model-options="{ getterSetter: true }" /> </div> When you set getterSetter to true, Angular will treat the referenced model attribute as a getter and setter method. When the function is called with no parameter, it’s a getter call and AngularJS expects that you return the current assigned value. AngularJS calls the method with one parameter when the model needs to be updated. New Module - ngMessages The new ngMessages module provides features for a cleaner error message handling in forms. It’s a feature that is not contained in the core framework and must be loaded via a separate script file. index.html: … <body> ... <script src="angular.js"></script> <script src="angular-messages.js"></script> <script src="app.js"></script> </body> app.js: // load the ngMessages module as a dependency angular.module('myApp', ['ngMessages']);  The first version contains only two directives for error message handling: <form name="myForm"> <input type="text" name="myField" ng-model="myModel.field" ng-maxlength="5" required /> <div ng-messages="myForm.myField.$error" ng-messages-multiple> <div ng-message="maxlength"> Your field is too long! </div> <div ng-message="required"> This field is required! </div> </div> </form> First, you need a container element that has an “ng-messages” directive with a reference to the $error object of the field you want to show error messages for. The $error object contains all validation errors that currently exist. Inside the container element, you can use the ng-message directive for every error type that can occur. Elements with this directive are automatically hidden when no validation error for the given type exists. When you set the “ng-messages-multiple” attribute on the element, you are using the “ng-messages” directive and all validation error messages are displayed at the same time. Strict-DI Mode AngularJS provides multiple ways to use the dependency injection mechanism in your application. One way is not safe to use when you minify your JavaScript files. Let’s take a look at this example: angular.module('myApp', []).controller('MyController', function($scope) { $scope.username = 'JohnDoe'; }); This example works perfectly in the browser as long as you do not minify this code with a JavaScript minifier like UglifyJS or Google Closure Compiler. The minified code of this controller might look like this: angular.module('myApp', []).controller('MyController', function(a) { a.username = 'JohnDoe'; }); When you run this code in your browser, you will see that your application is broken. Angular cannot inject the $scope service anymore because the minifier changed the function parameter name. To prevent this type of bug, you have to use this array syntax: angular.module('myApp', []).controller('MyController', ['$scope', function($scope) { $scope.username = 'JohnDoe'; }]); When this code is minified by your tool of choice, AngularJS knows what to inject because the provided string ‘$scope’ is not rewritten by the minifier: angular.module('myApp', []).controller('MyController', ['$scope', function(a) { a.username = 'JohnDoe'; }]); Using the new Strict-DI mode, developers are forced to use the array syntax. An exception is thrown when they don’t use this syntax. To enable the Strict-DI mode, you have to add the ng-strict-di directive to the element that you are using for the ng-app directive: <html ng-app="myApp" ng-strict-di> <head> </head> <body> ... </body> </html> IE8 Browser Support Angular 1.2 had built-in support for Internet Explorer 8 and up. Now that the global market share of IE8 has dropped and it takes a lot of time and extra code to support the browser, the team decided to drop support for the browser that was released back in 2009. Summary This article shows only a few new features added to Angular1.3. To learn about all of the new features, read the changelog file on Github or check out the AngularJS 1.3 migration guide. About the Author Sebastian Müller is Senior Software Engineer at adesso AG in Dortmund, Germany. He spends his time building Single Page Applications and is interested in JavaScript Architectures. He can be reached at @Sebamueller on Twitter and as SebastianM on Github.
Read more
  • 0
  • 0
  • 1983