Development

May Update – Web Development trends for 2018

Web Development Trends

In web development, the saying “the only constant is change” is very true. Web development is changing every second and 2018 is no exception. User expectations are growing and it is more important than ever to build digital experiences that are engaging, fun, and intuitive. Content needs to be accessible everywhere especially on mobile devices. In order to make that happen, new programming languages and frameworks are on the rise, extensions are becoming more compatible, and real time web apps are becoming more popular.

Web Development Trends for 2018

Web Development Trends You Can Expect in 2018

  • Vue JS is getting more popular
  • Functional programming benefits from JavaScript improvements
  • Extensions get more compatible
  • Real-time web apps are getting more popular
  • Progressive web apps grow in popularity
  • Mobile web development continues to expand
  • Material design is being used more and more

Rebecca Vogels’ article has more information on these web development trends.

More on Web Development Trends in 2018

1. In this first article by John Hughes covers these development trends:

  • An Increase in One-Page Website Designs
  • The Decline of the Flash Protocol
  • A Focus on Mobile-First Design Philosophy (Again)
  • The Increasing Importance of Push Notifications
  • The Prominence of Modular Page Creation
  • A Rise in the Popularity of Progressive Web Apps
  • The Perpetual Dominance of JavaScript

2. Anotni Zolciak’s article, focuses more on what kind of technology will matter on both front- and back-end:

  • Accelerated Mobile Pages
  • Progressive Web Applications (PWA)
  • Single Page Applications (SPA)
  • Chatbots and Online Support
  • Push Notifications
  • Static Websites
  • RAIL: User-Centric Performance
  • Motion UI
  • Functional Programming: What Is It?
  • Browser Extensions
  • Real-Time Web Apps
  • Augmented Reality and Virtual Reality

More Resources

  • Web Development Trends in 2018 article by Kumar Shantanu
  • Eight Web Development Trends Coming In 2018 article by Forbes
  • 8 Top Web Development Trends in 2018 article by MEREHEAD

Reading those articles now here is the conclusion that new frameworks, design trends, user expectations, and mobile developments are changing web development every day. Web development is responding to growing user expectations and design trends. Google’s material design, which is expected to gain even more popularity in 2018 as well. There is also the need to communicate and work together in real time from everywhere. We believe it is important for Web Professionals to know about these new trends and we encourage readers to review these articles..

This week we focused on those new trends emerging in 2018 in Web Professional’s world. We hope you find these resources and overviews useful. We always look forward to your comments and feedback (whether you are a member or not).

We encourage members (and non-members) check out our social media channels. If you aspire to be a web professional and don’t know where to start, we offer a number of beginning classes to our members via our School Of Web learning management system. As a member, your first class is free.

 

The post May Update – Web Development trends for 2018 appeared first on Web Professionals.

View full post on Web Professional Minute

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

Ink-trap development

Sometimes you see things that look a bit off and it makes you feel uneasy. When something challenges your sense of quality and what appears well-made. Like the following font:

Bell centennial demo

This doesn’t look good, and it doesn’t look right. It feels like someone didn’t quite finish it or didn’t know how to use tools. Or – even worse – didn’t use the right tools for the job. This font, for example, looks like my first attempts to get my head around vectors in Photoshop. Not a memory I cherish.

In the case of this font, though, nothing of this applies. What you see here is Bell Centennial by Matthew Carter, a well-regarded font expert. It is a font that has seen a massive amount of use.

You may not recall ever seeing it, but here’s the deal: Bell Centennial was the font used in AT&T phonebooks. The weird missing parts of the letters in it are so called “Ink Traps”. The genius of the ink trap is that it makes the font work when applied in its natural environment.

inktraps

Phone books shouldn’t cost much to print, which is why they use cheap paper. They also are big and should use small fonts, allowing for more content in fewer pages. In essence, the implementation phase of the project phone book tried to cut corners. Staying as cheap as possible.

This is where the ink traps come in. Ink bleeds out on cheap paper and blurs the letters. A font with no spaces can thus become unreadable. Not so Bell Centennial. On the contrary – it gets better and more legible when printed. The ink traps fill with ink and make the weirdness of the font go away.

M in design and in print

Bell Centennial in use

I like this approach a lot. There is a lot of merit in creating something and assuming a flawed implementation. As they all are in one way or another. By leaving things out to become available later – or not at all – we can concentrate on what’s important. A solid base that may not be perfect, but will not expect the implementer to do everything right, either.

Because they never do. In twenty years in this industry I’ve never seen a project get out the door the way we planned it to. It was even more common to see projects getting cancelled halfway through. And not only waterfall projects. Even the safeguard of the Agile Manifesto keeps failing.

In-build failure obscured just enough to make money

When I worked for an agency in the B2B space this seems to be even a common theme. Get the project, make sure you have a nice round sum in the contract that you have to pay in case you fail. Then pad the project with lots of unnecessary but expensive heads in the early stages. Bill all those to the client. Mess up and pay the fine when everything goes pear-shaped, leaving you with a nice profit.

We want to build for the future…

As a technical person, these projects were frustrating to work on. We’re lazy. We don’t want to do the same things over and over again. We want to do something and then automate it. We are all about making sure what we do is maintainable, extensible and follows standards. Because that makes outcomes predictable. For years we’ve been preaching that our code should be cleaner. It shouldn’t make assumptions. It should allow for erroneous data coming in and trying to fix it. It should be generic, not specific. We preach all this to avoid unpleasant surprises in the future.

Future imperfect

And yet, I have a hard time remembering when projects that we put so much effort in ever became a reality. They got out, yes, but somewhere along the way someone cut corners. And what is now live was never something I was particularly proud of. Other projects, that appeared rushed and made me feel dirty got out and flourish. Often they also vanished soon after, and oddly enough, the sky didn’t fall on our heads. Nobody missed them. They’ve done their job and overstayed their welcome. It was wasted effort to make them scale to forever and try to predict all the future needs. As there was no future for them. It is easier to fold and restart a software project than to dismantle and change a physical product. That’s the beauty of software. That’s what makes it soft.

I’ve hardly ever seen rewards of the hard work of making products maintainable in a clean manner. I am not saying they don’t make sense. I am saying that far too often, something got in the way. Something I had no control over. Often things I didn’t even hear about until things went pear-shaped:

  • Our well-thought-out design system hardly ever evolved with the product. Instead redesigns would wipe them out completely. Or the product would move to another CMS or backend. Out of a sudden this brought new limitations incompatible with the original design.
  • Our clean, accessible and semantic templates have a similar fate. Tossed around a few cycles of maintenance someone will have removed or warped the goodness we added upfront. Audits will flag this up, but with no immediate repercussions the invalid bits will end up on the backlog. There’s new things to add, after all.

New toys with new battery requirements

A common scenario is new product owners trying to make their mark by bringing the new tech hotness. Hotness they don’t understand and don’t hire able people for. Instead, it means starting new and following the “best practices” of the new hotness. What works for Facebook will also scale and apply to this internal payroll system, right?

Is failure a given? Maybe…

I’m sorry if this sounds bleak, but this seems to be a good time to re-consider what we are doing. We had a few decades of computers turning from a tool for scientists to them becoming an integral part of life. And this means we need to level up our game. This is not a cool tech thing to play with. This is a integral part of life. People’s identities, freedom, security, safety and happiness are dependent on it.

Broken toys

The quality of what we rely on isn’t that encouraging. If anything, a lot of the sins of the past now come to light – even on a processor level. We built a lot of spur-of-the-moment, good-enough things and hoped nobody looks closer. Well, the bad players of the market seem to be the ones looking and taking advantage.

When in the past we hid odd code in obscure byte code we now create huge dependency chains and lots of components. Components easy to re-use. Components not under the scrutiny of any quality assurance or security audits. Instead we rely on the wisdom of the masses and the open source community.

This would work, if the OSS world hadn’t exploded in the recent years. And if we didn’t tell newcomers to “not worry” and “just use what is there” to be more effective. We’re chasing our tail trying to be more effective and creating a lot with not much code. We move further and further away from the implementers and maintainers of our code. That’s what abstraction offers. Nobody likes maintenance. But it is probably the most important part there is. Any non-maintained project is a potential attack vector.

We forget that someone, somewhere needs to ensure that what we do doesn’t become a security nightmare. Instead, we create tools that check existing solutions for problems after the fact. This is a good measure, but it kind of feels self-serving. It also assumes that companies care to use these tools. And how they use it.

Case study: when the law required accessibility

I remember accessibility going through the same motions. When being accessible to people with impaired abilities became a legal need, people started to care. They didn’t care enough to look into their process of creating accessible products, as in – start with a sensible baseline. They didn’t want to understand the needs. They wanted to know how not to get sued. They bought a tool to check what’s obviously broken. They displayed a “Bobby Approved” or WCAG-AAA compliant banner on their web sites. They achieved that by adding alternative text like “image” to images. Satisfying the testing tool instead of creating benefit to visually impaired users.

This enraged the purists (including me) as it showed that people didn’t understand why we wanted things to be accessible. So we ranted and shone bright lights at their mistakes to shame people into doing the right thing. The net effect was that people stopped reaching out to experts when it came to accessibility. Instead they hired third party vendors to care on their behalf and build the thing needed to not get sued.

A lack of shared responsibility

It makes you wonder if we are trying too hard. If the current messy state of affairs in the whole of IT is based on a lack of shared responsibilities. Communication doesn’t help if it only states “don’t worry, it works”. An “of course our product will scale with you” is worrying without any shared ownership of the “how”. There is a disconnect between what we build and who maintains and uses it that leaves everyone involved disappointed.

This is tough to swallow and does rattle a few basic pillars of how we make money in the IT world. We build products and frameworks that enable people to do their jobs. We don’t want them to mess with the products though, so they become very generic. Generic solutions are less likely to give an optimised experience. They also are less likely to result in performant solutions catered to the current need. We throw in the kitchen sink and the plumbing and wonder why people run out of space. And we get angry when they start fiddling with the wrong pipes or don’t fix those that leak as long as the water runs.

Many products are terrible, but everyone involved didn’t do anything wrong

We’re quick to complain about users not doing things right. But we also never cared much about how people use our products. We hand this task over to the UX people, the trainers, the help desk and the maintenance staff. It is easy to complain about systems we have to use and wonder how on earth these things happened. The reason is simple: we created generic solutions and tweaked the output. We didn’t remove any extra features, but made them options to turn on and off instead. Many of our solutions are like a car with five steering wheels in different sizes. We expect the drivers to pick the right one and get cross when they’re confused.

Ink-trap development?

Maybe this is a good time to reflect and consider an approach like Matthew Carter did. We know that things will go wrong and that the end product is not perfect. So we optimise for that scenario instead of offering a huge, generic solution and hope people only use what they need. Maybe coding isn’t for a small, elite group to deliver interfaces to people. Maybe we need to have more involvement all the way from design to use of our products and we will create what is needed. This means that a lot more development would be in-house rather than buying or using generic solutions. Sure, this will be much more boring for us. But maybe not trying to predict all the use cases people might use our products for will give us more time to have a life outside of our work.

Working in IT isn’t an odditiy any longer, it is one of the few growing job markets. Maybe this means we have to dial back our ambitions to change the world by building things people don’t have to understand. Instead, we could try to build products based on communication upwards and sideways. And not those that only get feedback from user testing sessions once in a blue moon. People are messy. Software won’t change that. But it could give people ways to mess up without opening a whole can of worms by sticking to features people really need and use. We can always expand later, can’t we?

View full post on Christian Heilmann

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

Working with All Star Code in NYC to empower minorities to get into development

Sometimes it is great to work for a large company that gives you opportunities to do some good. I am currently in New York to run a workshop with All Star Code in our offices. Originally Aaron Gustafson was supposed to also be part of this but he got sick. Instead I am happy to work with Rachel White, Claudius Mbemba and Adina Shanholtz to help All Star Code.

Originally All Star Code approached me to get a bulk order for Surfaces for their students to work with. When I heard that their curriculum was involving Git, Node, Web Development and Debugging in Browsers and the stack was Sublime Text and Chrome Devtools I offered a small change. So now we’ll be teaching the teachers of All Star Code’s next course how to use Visual Studio Code and do all the development and debugging inside that one. My main driver there was that Code is open source and thus the students don’t need to get another license.

If you wonder what All Star Code does you can head over to the Decoded Chats blog, where I interviewed Mahdi Shadkamfarrokhi, their head of curriculum.

If you prefer to have an audio version, you can download it here (MP3, 18MB)

Here are the questions I asked:

  1. You work for All Star Code. Can you give us a quick introduction what that is and what you do? (00:13)
  2. How low are the numbers of developers that came from a minority background? What are the main reasons? (01:40)
  3. Do you think that by teaching communication skills together with technological skills you become more interesting for someone with a less privileged background? Is selling technology skills as a part of a whole package more successful? (02:49)
  4. The program has been running for quite a while. Is there a success story you are really proud of? (04:20)
  5. You learn a lot by teaching as you can’t fake it – you have to know. Do you find that it is easier to keep your skills up-to-date by running this program? (04:46)
  6. What are the biggest barriers for your students to get into development? Is it hardware access? Connectivity? The style and language of documentation out there? (06:14)
  7. I learned a lot because when I started computers didn’t do much and you had to program. Do you think that nowadays kids are less inclined to learn as computers are more seen as a consumption device? (07:47)
  8. There is a vast amount of online courses to choose from when it comes to learning how to program. Many of them decayed a bit after the first round of funding dried out. How do you find great and trustworthy resources? (10:10)
  9. A lot of creativity happens on the web but these makers don’t know or don’t get into professional development. Where do you go to find people for your course? (12:04)
  10. Do you see Open Source and services like GitHub to host, document and discuss your projects as an opportunity for newcomers? (14:49)
  11. How can people help you? Are there ways to volunteer? (18:07)

I’m very excited to be working on this.

View full post on Christian Heilmann

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

HTML 5 game development video series

Do you want to develop a game? Here’s an introductory video series to get you started on HTML 5 game development!

Why HTML 5

The first video offers some reasons to consider making a game for the web: the power of having no friction in distribution, the freedom from siloed marketplaces, the choice of tools and APIs that are available to you, etc.

Engines and libraries

The second video provides an overview of the current engines and libraries you can use to create your game. We cover pure JavaScript libraries (such as Phaser) as well as multi-platform engines that can export to HTML 5 (such as Unity).

Firefox developer tools

Next in series, we have a hands-on video that shows how to use the developer tools in Firefox Developer Edition to debug and profile your game. Modifying code on the fly, adapting our game to different screen sizes, debugging… it’s all here!

Tips for game jams

Last, there is a video for all of you joining a game jam –these competitions where you develop a game over a weekend. I have participated in many, and I know first-hand how hard and challenging game jams are! I hope these tips might be of help.

And don’t forget, if you create an HTML 5 game, tell us about it here. I’d love to play it!

View full post on Mozilla Hacks – the Web developer blog

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

Web Professional trends – 2016 – web development

In many ways, 2016 is shaping up to be an incredible year for changes in web development. Of course, that statement also applied to 2015, 2014; the more things change, the more they remain the same. That being said, here are some trends we see that we believe Web Professionals (particularly web developers and project managers) need to know about this year. These seem to be gaining momentum (and are the most obvious as we write this).

 

NoSSQL databases will be used more and more. Massive amounts of data (and associated analytics) are being used in applications and these applications (and analytics) are more real time than ever before. This is why we see trends like the InnoDB engine being added to MySQL. Availability and speed seem to be the focus today. For example, applications like Moodle rely more and more on InnoDB.

 

Animations are making a comeback to draw attention to parts of a page. This can be as simple as parallax scrolling or animations as one hovers over a part of a web page. Yes, CSS can be employed for some of these effects, but many will continue to rely on JS frameworks.

 

Page load speed is also becoming increasingly important. Most site visitors do not want to wait more than a few moments for a page to load. Keep in mind that we just stated animations are making a comeback (so your animations must load quickly – use CSS-3 where appropriate instead of JavaScript). Take advantage of approaches to reduce page load times (whether using a CDN [Content Delivery Network] or using GZIP to compress images and text).

 

There remain a number of language choices. For example, JavaScript and Java remain the most popular on GitHub. Make certain you are well versed in more than one (for example, JavaScript, PHP, and Python). Make certain you have examples to show to potential clients. Make certain you understand how to employ secure coding techniques in the languages you use. Details can be found at GitHub.

 

The use of containers (relying on Docker) will continue to grow. The big advantage to this approach is that one container has the dependencies to run the application. We don’t need to focus so much on the environment where the application will be deployed. This quote (from the Docker website) sums up this approach:

 

“Docker containers wrap up a piece of software in a complete filesystem that contains everything it needs to run: code, runtime, system tools, system libraries – anything you can install on a server. This guarantees that it will always run the same, regardless of the environment it is running in.”

 

Ok, what does this mean for web professionals? We already know that page load times matter. So does responsive design. We need to continue to reinforce that message to clients (and potential clients). Have a set of specific reasons why these items matter. Prepare and present your arguments using the lens of business. For example, if a page takes too long to load, it is likely our customer will go to a competitor’s website. Here is how we can reduce the load times…

 

Are you comfortable talking about NoSQL? Do you have an example of a project where you used NoSQL?  What about containers/ Docker? Can you explain these in terms a business client will understand? If not, spend some time developing basic information to share with clients. Help them understand why these trends are important. Most importantly, time is money. This is why containers are gaining in popularity so quickly. The old approach of creating virtual environments takes a lot of time (and most businesses don’t have that time to spend these days). Similarly, NoSQL is rising because of the amount of data and need to access it quickly. No, these databases may not meet all the ACID requirements. But you still need to know about them as your partners and clients will also be observing these trends (and wanting to use them in new projects this year).

 

Now is a good time to retool if you are not that familiar with these trends.

 

As an association for web professionals and those that teach, our goal is to keep you current with these trends. Also, we’re working on developing course structure on our training portal at our schoolofweb.org.

 

We hope that your new year is off to a great start.

Best always,
Mark DuBois, Community Evangelist and Director of Education

The post Web Professional trends – 2016 – web development appeared first on Web Professionals.

View full post on Web Professional Minute

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

Black Box Driven Development in JavaScript

Sooner or later every developer finds the beauty of the design patterns. Also, sooner or later the developer finds that most of the patterns are not applicable in their pure format. Very often we use variations. We change the well-known definitions to fit in our use cases. I know that we (the programmers) like buzzwords. Here is a new one – Black Box Driven Development or simply BBDD. I started applying the concept before a couple of months, and I could say that the results are promising. After finishing several projects, I started seeing the good practices and formed three principles.

What is a black box?

Before to go with the principles of the BBDD let’s see what is meant by a black box. According to Wikipedia:

In science and engineering, a black box is a device, system or object which can be viewed in terms of its input, output and transfer characteristics without any knowledge of its internal workings.

In programming, every piece of code that accepts input, performs actions and returns an output could be considered as a black box. In JavaScript, we could apply the concept easily by using a function. For example:

var Box = function(a, b) {
    var result = a + b;
    return result;
}

This is the simplest version of a BBDD unit. It is a box that performs an operation and returns output immediately. However, very often we need something else. We need continuous interaction with the box. This is another kind of box that I use to call living black box.

var Box = function(a, b) {
    var api = {
        calculate: function() {
            return a + b;
        }
    };
    return api;
}

We have an API containing all the public functions of the box. It is identical to the revealing module pattern. The most important characteristic of this pattern is that it brings encapsulation. We have a clear separation of the public and private objects.

Now that we know what a black box is, let’s check out the three principles of BBDD.

Principle 1: Modulize everything

Every piece of logic should exist as an independent module. In other words – a black box. In the beginning of the development cycle it is a little bit difficult to recognize these pieces. Spending too much time in architecting the application without having even a line of code may not produce good results. The approach that works involves coding. We should sketch the application and even make part of it. Once we have something we could start thinking about black boxing it. It is also much easier to jump into the code and make something without thinking if it is wrong or right. The key is to refactor the implementation till you feel that it is good enough.

Let’s take the following example:

$(document).ready(function() {
    if(window.localStorage) {
        var products = window.localStorage.getItem('products') || [], content = '';
        for(var i=0; i<products.length; i++) {
            content += products[i].name + '<br />';
        }
        $('.content').html(content);
    } else {
        $('.error').css('display', 'block');
        $('.error').html('Error! Local storage is not supported.')
    }
});

We are getting an array called products from the local storage of the browser. If the browser does not support local storage, then we show a simple error message.

The code as it is, is fine, and it works. However, there are several responsibilities that are merged into a single function. The first optimization that we have to do is to form a good entry point of our code. Sending just a newly defined closure to the $(document).ready is not flexible. What if we want to delay the execution of our initial code or run it in a different way. The snippet above could be transformed to the following:

var App = function() {
    var api = {};
    api.init = function() {
        if(window.localStorage) {
            var products = window.localStorage.getItem('products') || [], content = '';
            for(var i=0; i<products.length; i++) {
                content += products[i].name + '<br />';
            }
            $('.content').html(content);
        } else {
            $('.error').css('display', 'block');
            $('.error').html('Error! Local storage is not supported.');
        }
        return api;
    }
    return api;
}
 
var application = App();
$(document).ready(application.init);

Now, we have better control over the bootstrapping.

The source of our data at the moment is the local storage of the browser. However, we may need to fetch the products from a database or simply use a mock-up. It makes sense to extract this part of the code:

var Storage = function() {
    var api = {};
    api.exists = function() {
        return !!window && !!window.localStorage;
    };
    api.get = function() {
        return window.localStorage.getItem('products') || [];
    }
    return api;
}

We have two other operations that could form another box – setting HTML content and show an element. Let’s create a module that will handle the DOM interaction.

var DOM = function(selector) {
    var api = {}, el;
    var element = function() {
        if(!el) {
            el = $(selector);
            if(el.length == 0) {
                throw new Error('There is no element matching "' + selector + '".');
            }
        }
        return el;
    }
    api.content = function(html) {
        element().html(html);
        return api;
    }
    api.show = function() {
        element().css('display', 'block');
        return api;
    }
    return api;
}

The code is doing the same thing as in the first version. However, we have a test function element that checks if the passed selector matches anything in the DOM tree. We are also black boxing the jQuery element that makes our code much more flexible. Imagine that we decide to remove jQuery. The DOM operations are hidden in this module. It is worth nothing to edit it and start using vanilla JavaScript for example or some other library. If we stay with the old variant, we will probably go through the whole code base replacing code snippets.

Here is the transformed script. A new version that uses the modules that we’ve created above:

var App = function() {
    var api = {},
        storage = Storage(),
        c = DOM('.content'),
        e = DOM('.error');
    api.init = function() {
        if(storage.exists()) {
            var products = storage.get(), content = '';
            for(var i=0; i<products.length; i++) {
                content += products[i].name + '<br />';
            }
            c.content(content);
        } else {
            e.content('Error! Local storage is not supported.').show();
        }
        return api;
    }
    return api;
}

Notice that we have separation of responsibilities. We have objects that play roles. It is easier and much more interesting to work with such codebase.

Principle 2: Expose only public methods

What makes the black box valuable is the fact that it hides the complexity. The programmer should expose only methods (or properties) that are needed. All the other functions that are used for internal processes should be private.

Let’s get the DOM module above:

var DOM = function(selector) {
    var api = {}, el;
    var element = function() {}
    api.content = function(html) {}
    api.show = function() {}
    return api;
}

When a developer uses our class, he is interested in two things – changing the content and showing a DOM element. He should not think about validations or change CSS properties. In our example, there are private variable el and private function element. They are hidden from the outside world.

Principle 3: Use composition over inheritance

One of the popular ways to inherit classes in JavaScript uses the prototype chain. In the following snippet, we have class A that is inherited by class C:

function A(){};
A.prototype.someMethod = function(){};
 
function C(){};
C.prototype = new A();
C.prototype.constructor = C;

However, if we use the revealing module pattern, it makes sense to use composition. It is because we are dealing with objects and not functions (* in fact the functions in JavaScript are also objects). Let’s say that we have a box that implements the observer pattern, and we want to extend it.

var Observer = function() {
    var api = {}, listeners = {};
    api.on = function(event, handler) {};
    api.off = function(event, handler) {};
    api.dispatch = function(event) {};
    return api;
}
 
var Logic = function() {
    var api = Observer();
    api.customMethod = function() {};
    return api;
}

We get the required functionality by assigning an initial value to the api variable. We should notice that every class that uses this technique receives a brand new observer object so there is no way to produce collisions.

Summary

Black box driven development is a nice way to architect your applications. It provides encapsulation and flexibility. BBDD comes with a simple module definition that helps organizing big projects (and teams). I saw how several developers worked on the same project, and they all built their black boxes independently.

View full post on Mozilla Hacks – the Web developer blog

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

Web Professional Trends for 2014 – Web Development with Raymond Camden

In this 10 minute interview with Raymond Camden, Developer Evangelist at Adobe Systems we talk about Web Professional Trends for 2014 including Web Development Trends and:

* How automation and scaffolding improvements will make projects set up easier and faster for Web developers
* Some industry and product consolidation and simplification will take place
* Lots of opportunities for designers and developers and those that straddle both
* Mobile Application Development provides great opportunity
* Recommended skills include Java and Objective C for both Android and IOS
* Hybrid tools like PhoneGap support non-programmers to participate in the mobile app development space

The post Web Professional Trends for 2014 – Web Development with Raymond Camden appeared first on Web Professionals.

View full post on Web Professional Minute

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

Web Professional Trends 2014 – Web Development with Charles Wyke-Smith

In this 5 minute interview with Charles Wyke-Smith, CEO @BublishMe we talk about Web Professional Trends in Web Development and Design for 2014 and:

• A shift to applications that have two binding associated with them
• Trends that will save you time and money
• Front end frameworks like NodeJS. Angular, Ember and Backbone
• JSON Databases
• Moving from Sql to JSON formats
• JavaScript Middleware
• Benefits of Angular to both Web developers and designers
• Roles, responsibilities and skills for Web developers and Web designers alike
• Underscore and handlebars and resources for Web designers

Node.js
Node.js is a platform built on Chrome’s JavaScript runtime for easily building fast, scalable network applications. Node.js uses an event-driven, non-blocking I/O model that makes it lightweight and efficient, perfect for data-intensive real-time applications that run across distributed devices. For additional information visit http://nodejs.org/

Why AngularJS?
According to AngularJS.org, HTML is great for declaring static documents, but it falters when we try to use it for declaring dynamic views in web-applications. AngularJS lets you extend HTML vocabulary for your application. The resulting environment is extraordinarily expressive, readable, and quick to develop. Other frameworks deal with HTML’s shortcomings by either abstracting away HTML, CSS, and/or JavaScript or by providing an imperative way for manipulating the DOM. Neither of these address the root problem that HTML was not designed for dynamic views. Extensibility. AngularJS is a toolset for building the framework most suited to your application development. It is fully extensible and works well with other libraries. Every feature can be modified or replaced to suit your unique development workflow and feature needs. For additional information visit http://angularjs.org/

What is Ember?
Ember.js is free, open source resource for Web professionals. According to EmberJS, Ember is a framework for creating ambitious web applications. Write dramatically less code with Ember’s Handlebars integrated templates that update automatically when the underlying data changes. Don’t waste time making trivial choices. Ember.js incorporates common idioms so you can focus on what makes your app special, not reinventing the wheel. Ember.js is built for productivity. Designed with developer ergonomics in mind, its friendly APIs help you get your job done—fast. For additional information visit http://emberjs.com/

JSON
JSON (JavaScript Object Notation) is a lightweight data-interchange format. According to JSON.org It is easy for humans to read and write. It is easy for machines to parse and generate. It is based on a subset of the JavaScript Programming Language, Standard ECMA-262 3rd Edition – December 1999. JSON is a text format that is completely language independent but uses conventions that are familiar to programmers of the C-family of languages, including C, C++, C#, Java, JavaScript, Perl, Python, and many others. These properties make JSON an ideal data-interchange language. For additional information visit http://www.json.org/

Backbone.js
Backbone.js gives structure to web applications by providing models with key-value binding and custom events, collections with a rich API of enumerable functions, views with declarative event handling, and connects it all to your existing API over a RESTful JSON interface. For additional information visit Backbone.js

Underscore is a utility-belt library for JavaScript that provides a lot of the functional programming support that you would expect in Prototype.js (or Ruby), but without extending any of the built-in JavaScript objects. It’s the tie to go along with jQuery’s tux, and Backbone.js’s suspenders. Underscore provides 80-odd functions that support both the usual functional suspects: map, select, invoke — as well as more specialized helpers: function binding, javascript templating, deep equality testing, and so on. It delegates to built-in functions, if present, so modern browsers will use the native implementations of forEach, map, reduce, filter, every, some and index. For additional information visit http://underscorejs.org

HandleBarJS
Handlebars provides the power necessary to let you build semantic templates effectively with no frustration.
Mustache templates are compatible with Handlebars, so you can take a Mustache template, import it into Handlebars, and start taking advantage of the extra Handlebars features. For additional information visit http://handlebarsjs.com/

About Charles Wyke –Smith
A creative media professional focused on developing enterprise online SaaS applications and web sites that provide excellent user experience and quantifiable ROI. Charles has consulted and developed online applications, web sites and multimedia for Palm, Wells Fargo, ESPN Videogames UCSF, and Benefitfocus, and have held VP and other senior positions for online companies. The third edition of “Stylin’ with CSS” was published in November 2012. The first two editions have sold over 30,000 copies. “Scriptin’ with JavaScript and Ajax” was published 2009. and “Codin’ for the Web” in 2006, all on the New Riders imprint of Peachpit Books. The second edition of Stylin’ was published in December of 2007. He also published an eBook, “Visual Stylin’ with CCS3″, that was published in August 2012 that covers the advanced design and animation capabilities of CSS3.
For additional information visit ttp://www.stylinwithcss.com/

About Bublish’
Create book bubbles in seconds like the one to the right. Share them on multiple social networks as well as here on bublish.com.
Sharing your writing and insights is a fun and powerful way to be discovered by new readers.’ For additional information visit http://bublish.com/

The post Web Professional Trends 2014 – Web Development with Charles Wyke-Smith appeared first on Web Professionals.

View full post on Web Professional Minute

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

Mobile Application Development Technologies and Opportunities

Mobile Application Development Technologies and Opportunities – Interview with Jonathan Rende

In this 13 minute interview with Jonathan Rende, Vice President Products @Appcelerator we talk about:

* Native vs Mobile Application Development with HTML5
* Skills required for both
* The pros and cons of both
* Tools that can leverage existing HTML, CSS and JavaScript skills to develop robust Native apps
* Job opportunities Mobile Application Development.

The post Mobile Application Development Technologies and Opportunities appeared first on Web Professionals.

View full post on Web Professional Minute

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

Firefox OS Development: Web Components and Mozilla Brick

In this edition of “Firefox OS: The platform HTML5 deserves” (the previous six videos are published here), Mozilla’s Principal Evangelist Chris Heilmann (@codepo8) grilled Mozilla’s “Senior HTML5 Engineer Angle Bracket Coordinator” Matthew Claypotch (@potch) about the exciting new possibilities of Web Components for Web App developers and how Mozilla’s Brick library, a collection of custom elements to build applications with, can help with the transition. You can watch the interview on YouTube.

The Why of Web components

There is a problem with the Web as a platform for applications: HTML, the language that makes it easy to mark up documents and give them meaning doesn’t have enough elements to build applications. There are quite a few new elements in the HTML5 spec, but their support is sketchy across browsers and there are still a lot of widgets missing that other platforms like Flex or iOS give developers out-of-the-box. As a result, developers build their own “widgets” like menu bars, slider controls and calendars using non-semantic HTML (mostly DIV elements) and make them interactive using JavaScript and theme-able using CSS.

This is a great workaround but the issue is that we add on top of the functionality of browsers instead of extending the way they already function. In other words, a browser needs to display HTML and does a great job doing that at least 60 frames per second. We then add our own widget functionality on top of that and animate and change the display without notifying the browser. We constantly juggle the performance of the browser and our own code on top of it. This leads to laggy interfaces, battery drain and flickering.

To work around that problem a few companies and standards body members are working on the Web Components specification which allows developers to extend the browser’s understanding of markup with own elements. Instead of writing a slider control and make it work after the browser already displayed the document, you define a slider element and become part of the normal display flow. This means our widgets get more responsive, don’t work against the browser’s rendering flow and all in all perform better. Especially on low spec mobile devices this is a massive win. The whole thing already happens: if you for example add a video element to the document you see a video controller with a timed slider bar, a play button and volume controls. All of these are HTML, CSS and JavaScript and you can even see them in the debugging tools:

Anatomy of a video element

Firefox OS, being targeted at low end devices can benefit a lot from widgets that are part of the rendering flow, which is why Mozilla created Mozilla Brick, a collection of custom elements to build applications with. Earlier we introduced the concept using a library called XTags, which powers Brick. Using Brick, it is very simple to create for example a deck based application layout using the following markup:

<x-deck selected-index="0">
  <x-card>
    0<span>I'm the first card!</span>
  </x-card>
  <x-card>
    1
    <span>
      These cards can contain any markup!<br>
      <img src="../../site/img/grounds_keeping_it_real_s3.gif">
      <img src="../../site/img/grounds_keeping_it_real_s1.gif">
      <img src="../../site/img/grounds_keeping_it_real_s2.gif">
    </span>
  </x-card>
  <x-card>
    2 <img src="../../site/img/thumbs_up.gif">
  </x-card>
</x-deck>

The resulting app consists of three decks that can be animated into another without having to do anything but call a deck.shuffleNext(); function.

Web Components are a huge topic right now and many libraries and frameworks appear each week. We hope that by using Brick we can enable developers to build very responsive apps for Firefox OS quickly and cleanly and leave the pain of making your app perform really well up to the OS.

View full post on Mozilla Hacks – the Web developer blog

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)