JavaScript is growing up.  As it matures, we see more and more improvement associated with JavaScript testing and deployments.  One area I get a lot of questions about is unit testing, more specifically, unit testing private methods.

Traditional revealing module pattern.

When dealing with this issue, there are two main approaches commonly used.   The first is to test the method through another public method that calls it.  The other would be to expose it publicly even if the only thing that needs access to it are the unit tests.  Neither strategy is perfect or ideal but here are a couple of things to consider when choosing which is best for you.

Testing your private method by calling a public method that calls it.

Start off by considering your objective.  My objective is to be able to make changes to the code-base with confidence.  Additionally, if an issue presents itself, I want to be able to find and address the issue quickly.

When you have several private methods chained together, it becomes no different to test than one big super method.  If there’s a problem with the logic, it can be cumbersome to track down the issue.  On the flip side of that, if every method were public, you could test each method and ensure that it’s doing its little bit of work correctly.  All of the methods doing their one job adds up to a complete workflow.  If one of the methods fails to do its job, it’s quick and easy to identify where the issue lies.   The drawback is that we totally destroyed the notion of a public vs. private methods and all the good things that come along with it.

One approach that I’ve taken with several companies is a hybrid.  I will follow a classic module pattern and expose publicly only those methods that are called externally from outside the class.  Then I create a ‘testObject’ and expose it publicly.  The properties of my testObject are all the private methods that I otherwise would not be able to test.  Now all my private methods are exposed publicly.  While it’s not nearly as safe as keeping them private, at least I know that  I should only ever see ‘class.testOject.somePrivateMethod’ being called from within my unit tests.  If I ever do a code review and see someone calling ‘class.testObject.*’ in the core code, I know someone is calling the private method in a way it’s not intended.

Hybrid testing pattern. Exposing your private methods through a single test object.

It’s a great pattern and has worked very well for several enterprise implementations.  It’s not perfect but is a good compromise in most cases.  You’ll want to consider your application and the pros and cons of the various strategies before deciding which is best for you.

Read More at Unit Testing Private Methods in Javascript

The word “accordion” typically conjures a mental image of your favorite polka band. However that’s not what we are talking about when referring to accordion menu. Although polka music can offer a rip-snorting good time, the term is associated with something different in the realm of web design. User interface accordions might refer to menus, widgets, or content areas which expand like the musical instrument. These interfaces have grown a lot more popular in recent years with the expansion of JavaScript and more prominently jQuery.

I’d like to cover a series of examples and techniques for building accordion interfaces into any website layout. Accordions are popular because they allow developers to force large amounts of content into tiny spaces on the page. Granted these content displays also require dynamic effects for switching between page elements – so there are pros and cons to accordions. This post should outline the important concepts and topics related to accordion interface design.

Why use Accordion Menus?

I like to think of accordions as content management tools. When you have a page that’s broken into dozens of paragraphs, links, images, or just too many blocks of content… accordion menus to the rescue.

Not every website needs an accordion menu and you certainly won’t find them all the time. But that’s no reason to ignore the concept entirely. The purpose of an accordion menu is to manage an overabundance of content through dynamic switching. And you can build quick accordions if you use website builders or CMS engines like WordPress.

But each interface works differently based on the circumstances of the layout & the type of website.

Nowadays the biggest concerning factor would be the total number of visitors who don’t have JS-supported browsers. Over the past decade this number has dwindled considerably low as more people are upgrading their computers. This means you should have almost no concern because even mobile smartphone browsers support JavaScript. If the content is viewable and the accordion is usable then where’s the harm?

Just be sure that each accordion component has a real purpose. There are times where I’ve found accordion FAQ pages that could have just listed content down the page without forcing me to click on each heading. Granted I understand the premise but if each answer can be surmised in a few sentences, hiding that content isn’t going to improve the user experience.

So when exactly should you use accordions? Mostly with larger menus or content which might behave cleaner using expandable sections. These could be sub-headings or even multiple levels – the point is to organize content in a way that makes navigation simpler than endless scrolling.

Sliding Menu Effects

One of the most common interfaces you’ll experience is the sliding menu effect. This is usually vertical with a series of links hidden within sub-links. Clicking on a primary link will then expand the list of sub-links in a sliding animation.

Sometimes a website’s entire navigation menu is built on this accordion effect. Other common choices are dropdown menus which appear on hover – but accordion menus don’t slide over the page since they’re built into the page. So the effect is somewhat different and offers a different user experience by comparison.

Take a look at this Designmodo tutorial which explains the process of accordion development in a nice tutorial. The source code is free to download but it should really serve as an example describing how this interface might work. Designmodo has a live sample preview which demonstrates how the menu behaves in action.

Notice how the menu will automatically close when opening a new section. This is typical behavior when constructing an accordion menu because only one primary menu is open at any given time. But this is not a mandatory feature and, in fact, most accordion menus allow every section to be open. This choice depends largely on the website itself and how content is expected to behave.

CSS3 Tabbed Content

Another example of accordion content is based on tabbed widgets. So instead of having links listed vertically, tabs are used to manage shifting content. This is another really popular method of content management because JavaScript has made the process super easy. But since most developers are already familiar with JavaScript, I’d like to cover the more advanced techniques.

An alternative to JavaScript is the expandable accordion UI with CSS3. Granted they both seem like a risk but CSS3 has much less browser support. The only benefit is that CSS3 doesn’t require as much code and offers a simpler method of animation. If you prefer modern CSS3 animation check out the following tutorial:

Codrops publishes very high-quality content and their accordion CSS3 tutorial is no exception. The code is free and downloadable if you want to try it out yourself. Their live demo includes a couple different options which utilize checkboxes vs. radio buttons.

Checkboxes allow users to select multiple items at once. Using the checkbox method you can have many different content areas open at the same time. Radio buttons only allow one radio item to be selected. This means when opening a new section the previously-open section will close. Both work great and will vary based on the needs of each project.

Sliding Portfolio

Webpage content is managed via alternate pages for simplicity and ease-of-use. Visitors would rather browse through different pages rather than sift through a long single-page design. However working with collapsible accordion content makes the latter a lot more reasonable.

Take for example the homepage of Toko which uses a dynamic portfolio listing. As you click on each item the list will collapse smaller for an easier view of the project. This is by far an odd concept but it works great on their website. Why? Perhaps because of the minimalist design, perhaps because of the grid-like structure.

Either way portfolio sites can be an excellent choice for accordion widgets. Not every project should rely on accordions to best manage content. But think of the control you can offer visitors by organizing projects into larger categories and even sub-categories. Make use of this sparingly but keep it in mind.

Image Galleries

In a similar vein as the portfolio listing is a collapsable image gallery. In accordion-style this can take many forms as vertical, horizontal, slidable, tabbed, you name it! Touch-based interfaces have also allowed for swipeable image galleries that work nicely with computer mice too.

Getting back to Codrops I found another great tutorial covering an image accordion with CSS3. The effect is really cool and surprisingly supports click events. Each image is given some caption text which animates into view. What I like about this design is that it doesn’t rely on tabs or links or anything outside of the images themselves – so the content becomes the tabs. Pretty cool right?

Here’s a free jQuery plugin for building a responsive accordion image gallery. This example behaves similarly to the Codrops tutorial except all the animations are handled through jQuery. Also the caption text is a bit larger and seems more smooth. I’d like to state that either one of these effects could be duplicated and pushed onto the other – it’s simply a matter of recoding the design to fit the interface.

But my point is to demonstrate that both CSS3 and JavaScript can be used to create most of these effects. Unfortunately older browsers will never be backwards-compatible to support new CSS3 animation. Working with JavaScript is still the safest choice, but as more people upgrade their web browsers we can hope to see a future with primary support for CSS3.

Free Code Snippets

I’d like to wrap up this post by offering a collection of free open source code snippets. Each sample demonstrates the power of accordion content whether in a navigation, FAQ listing, or tabbed widget. All of these codes have been shared on CodePen and should be reusable on any project.

Granted you can always pick up a free plugin to rebuild something from scratch instead. Lots of developers release their code for free and try to help the community with free plugins. And of course there will always be those who prefer to build everything from scratch. But if time is a factor then I highly recommend working from these code snippets to ensure greater compatibility and a much quicker development schedule.

3D Accordion

Material List

Animated Accordion

CSS3 Dark UI

Full-Width Content

Multi-Level Accordion

Flyout Dropdown

Colored Bars

Multi-Level Accordion

Responsive Content

Sexy CSS Accordion

Dope Accordion Menu

Vertical Radios

Horizontal Radios

BEM Accordion

Pure CSS

Blue Accordion

Flexbox Tabs

Pure CSS Menu

Multi-Color Accordion

Read More at Best Practices for Accordion Menu in Web Design

Earlier today, Angular 2 Beta was announced, and with this, AngularJS has officially moved towards a new version, with many new changes and enhancements.

The Beta release is functional enough to let you build large applications using it, but as a matter of caution, it is advisable not to use it for production projects. 

With that out of the way, what does Angular 2 Beta bring to the table?

To begin with, Angular is expected to be much faster than Angular 1 in terms of performance and compilation. With view caching and faster compilation of scripts, Angular 2 will load faster and better. Plus, this release also comes with several security tweaks and fixes, in addition to, of course, a new architecture.

The Beta release is still far from perfect, and as of now, many new changes are expected to arrive, such as:

• Reduced payload size
• Usable Angular CLI for developmental process
• Support for animations
• Better support for ES6 and Babel
• Better documentation

AngularJS has become quite popular, and the fact that it is backed by Google makes it all the more attractive for web developers. In fact, if you head over to Made with Angular website, you will notice that AngularJS can, indeed, accomplish a lot and is a powerful tool for your projects.

If you are an existing user of Angular 1, be sure to read the migration guide before shifting to Angular 2 Beta. That said, you can download Angular 2 Beta from the homepage.

What do you think of Angular 2? Share your thoughts in the comments below!

Read More at Angular 2 Beta Has Been Announced

We seen an up-and-coming trend in design that will definitely bleed into 2016 for animation incorporated into UI. With the opposite trend of static websites emerging as well, some would argue otherwise. However, with the development of CSS3 and JavaScript, we see more and more developers embracing interactive animation in their programming. The development of clever little Javascript engines like Popmotion, make it even easier for developers to create and innovative user interfaced using animation.

The motion engine has become popular on Github, boasting abilities like animation, physics and input tracking; along with many more, like to following listed on the site:

• Input smoothing: Optionally smooth noisy data sources.
• Easy distribution: Available on npm, Bower, Meteor, or as a simple file-include.
• Low level: A single processing loop, open for low-level use.
• Watch: Values can watch other values and do as they do, faster than recalculating.
• Complex number support: Colors, path definitions, matrix transforms and more.

If you are looking to get started with animation, check out their handy introduction to animation.

Read More at Popmotion, Javascript Motion Engine for Animated UI

We are so honored to share a fascinating interview with Nicholas C. Zakas, a front-end engineer, author, and speaker, with our readers. He is a Principal Architect at Box and has worked on and lead several projects with Yahoo! where he worked as a Front-end Tech lead for the Yahoo! homepage. Nicholas personally shares his first unsettling year at Yahoo! and the solutions he created to help overcome some serious obstacles. Along with his contribution to Box’s success in their early years of immense growth and his impacting, long-term fight with Lyme disease to which he ultimately contributes part his success as a high-performance engineer.

How did you first get your start at Yahoo!?

Initially, I was set to interview with Google in California. I figured while I was there I could meet up with other people in California. I sent an email to a couple people out there including Thomas Shaw, the creator of YUI, and had a good conversation about the state of the web. He eventually told me that if I was considering moving all the way across the country, that I should also interview with Yahoo! I flew back to interview with Yahoo! and Google, In both cases I had the same reaction. Both events produced a high level of anxiety. I am to this date a very nervous air traveler. This trip, in particular, was very anxiety provoking because I had also never traveled on my own before. I was so nervous before the flight I threw up. To calm myself down I kept telling myself “this is just an experience, go in and see how it goes. I don’t need both of these guys, but this is a good possibility. If I didn’t get the job that was fine.”

I ended up getting offers from both companies.

How did you transition from Yahoo! to where you are now?

At the time I took the path less traveled, I choose to go to Yahoo! instead of Google. A lot of people ask me why I choose Yahoo! over google. It was really a question of fit. I felt like I fit better at Yahoo! over Google. I could picture myself better.

Once at Yahoo! I felt like a fish out f water for about 9 months. I was working with people who are incredibly smart and solved problems on such a massive scale. I came from pretty small companies, 100 – 300 and I was at a company who had 10K people when I was there. Even the intern of the group I was working with. I felt like the intern knew more than I did. I had never worked with Linux before and the intern knew Linux and looked down on me like “you don’t know what you’re doing”. I was really overwhelmed and wasn’t sure if I was going to cut it. but I took it as a challenge, working on my Yahoo! was a really great introduction and there was a lot of smart people surrounding me from which I could ask questions.

After about a year and a half there I felt like I found my stride. I stepped up into more of a lead position where I was being told that I was building some really high quality stuff and was tasked to teach other how I do things so we can raise the level of quality across the board. I started thinking more of what it means to be a tech lead and a lead software engineer vs someone who just does what they are told. That sort of transitioned me into a larger role onto the Yahoo! homepage where we were rewriting it from scratch, in a way that was very framework focused so that we could launch Yahoo! home pages that were specific to different locals. We could have one in India, France, Japan, China in the appropriate language for that local.

It was pretty daunting at the time. It’s one of those things where the first thing you ask is “What is the team?” because you need more than just two people to wrap their brain around just an elaborate project. Knowing that you have a good team around you is key. Myself and other people who were working on My Yahoo!, ended up being chosen to work on the Yahoo! Homepage project because of the great job we did on My Yahoo!.

The problem was in order of magnitude larger because of the traffic, ad revenue, and the requirement that the homepage can never go down; no 500 errors, no 404, no server failed to respond, that is just not acceptable. Every second is bringing in money, which means every second it’s down it is losing money. We had to get very deep into the product requirement for each region.

There were a lot of interesting challenges technically. It’s one thing to design a homepage to work for the US. When you switch to a country like Japan, where the topography of the characters is much more compressed, you end up with having to solve for a lot of extra whitespace. We also had to account for languages that are written from right to left without requiring for a whole new homepage design. There was also my first bite of being a leader on a large team, my manager made it clear that the responsibility for the entire homepage fell on me. That meant having to organize people, resources and technology to make sure that the homepage was running as smooth as possible. Worked with a team of about 24 people distributed between USA, London, India, and Korea. I had to figure out how to get all of these people working on the same code base, while staying out of each other’s way because they were all working in different time zones. That I look back on as my crucible in term of how a lot of best practices were developed in my mind. It was really the lessons that I learned there that lead me to the position at Box.

What are you focusing on with Box, and what unique challenges do you face there?

What attracted me to Box was that I was looking for a new challenge. I quickly came to realize at Yahoo! that I was solving the same types of problems in the same space. I really wanted to do something where the solution to the problem wasn’t already known to me. I was introduced to Box through a friend who had worked there. I realized that they were in a very interesting position. Box was growing like crazy, and the processes and technology were not keeping up.

There is a scaling problem, not just technology wise but also process-wise, it seemed like there was some basic automation that was missing that could alleviate some of the stress about not being sure if their code was going to break something or not.  I wasn’t entirely sure how i was going to fix everything but being able to help a rapidly growing company scale into a large company, a lot of people don’t get that kind of opportunity. I felt like I could make a significant difference to the company as a whole.

First was how do we automate a lot of manual processes, which was a problem that they started to work on before was there but there was a lot of things that were not being done like any sort of linting for JavaScript. Now we have a very robust linting system using ESLint that has our own plugable rules, now what we’re able to do, if we go through a post mortem of a product and discover that there is some JavaScript that was missing we just create a rule that will flag that from now on so we don’t encounter that same error again. We did a whole tooling upgrade where we have linting for CSS as well and improved the compression of images. Really optimizing our static asset pipeline by switching to UglifyJS which gave us better savings.

Also started digging into the process of how we communicate with one another. What I saw a lot of was complaining on code reviews about things where done. which isn’t bad, except you could get a lot of opposite opinions about how things should work because it really slows down the development products. One of the first things I did was get everybody together and decide on a style guide, then we were able to focus on higher level problems like, How code is structured? Is it structured well, will it lead to more bugs at the future?

After that I headed up a team called frontend frameworks and what we did was look at how we could start to create some decoupled pieces in our frontend. One of the complaints we heard a lot was “I’m afraid to make changes because when I do It tends to break something that is unrelated to what I’m working on, and we don’t find that, until a customer reports an error in productions.” And that’s a very bad situation to be in for an engineer. That was a top priority to solve, we have to give people confidence in the changes that they are making so that we will fix changes and they will fix bugs.In this case I knew that there was no possibility that we would be given time to rewrite the entire application. You rarely get to rewrite something from scratch that brings in a lot of revenue. IT just doesn’t happen. What you have to do is look for a path forward that you can do in an incremental way. We had to figure out a path, from the mess that we have now, to a pristine future knowing that you’re not going to get it all at once.

What we did was create a very small framework called T3, which is now open sourced. It’s primary goal was to create loosely coupled components that had very specific jobs; so that when you had to create something new you asked one question, Is this a behaviour, module, or a service? By limiting people’s choices, you give them confidence. Each of those component restrict and prevent you from negatively affecting your code or other people’s code. Essentially you are replacing small pieces of the application with T3 components without needing to rewrite everything with everything else continuing to work.

“We very slowly built up and continued to created Islands of sanity in an ocean of insanity, until eventually you had a giant island where people could function with a high level of confidence and get get to the point where they could write test without fear.”

I‘m not really trying to compete with ReactJS, AngularJS, or Backbone.JS. That was never the goal to get into a framework war or to convince that T3 was better. It was meant to help those who were in a similar situation to the one we were in, where you cannot afford to do a full rewrite; and you need something that can help you to organize your code and you need work alongside any other framework you already have, then T3 might be something that could help you make that transition to get to a better state.

What are you most excited about regarding new technologies that interest you?

The thing that I’m most excited about is how tooling has been improving by leaps and bounds for frontend engineers. I remember when I was first (in 2000) full time job doing web development if you had any sort of problem it was a nightmare trying to figure out what the problem was and how to prevent it in the future. Back then we put in alert statements everywhere in Javascript, to figure out where you code was going. In CSS you had to keep deleting things until you found what was causing you bad layout. It could literally take week to debug a typo! Because you didn’t have any insight to what was going on.

Looking at tools for front end engineers now is incredibly exciting! You have the Chrome DevTools, Firefox Developer Tools, even the new Microsoft Edge tools are incredible! You have things like Fiddler, a free debugging proxy, that lets you look really close at the HTDD that’s going in and out. There is a lot better linting tools, to toot my own horn, CSS Lint. There is a lot more in terms of testing, better automated testing solutions for JavaScript like Mocha, Tape and istanbul which gives you code coverage for JavaScript. I find myself relying on these tools do much now to give myself confidence that I have run enough tests. I rely on Webpack, module bundler and Browserify that make it easier to create JavaScript that can run on an brower and a server. I’m so excited about all this because the productivity gains we are getting out of our frontend engineers now and will continue to get as we move forward are really what I think is helping to push the web as a whole forward. The reason we are able to continue to evolve, and introduce new features to the web platform is because the tooling has gotten so good. It goes back to confidence, the better confidence that you can give engineers in what they are doing on a day to day basis, the more they will feel free to try new things, innovate, and fix old things. As a result you see the feedback loop becoming a lot tighter, even with ECMAScript 6 (ES6) which long time to finalize, you have tools like Babel (JavaScript compiler tool) that people started using and where able to give feedback into the process, in order to find problems, so when ES6 was finalized people wouldn’t run into those same issues.

Do you see potentially a book on some of these tools you use, to help other people learn tools before they need to know this?

IT’s been a thought. I’m working on a book on ECMAScript 6 that should come out next year, that’s where I’m focusing a lot of my energy. I did make a brief attempt at doing an overview of tooling in my book Maintainable JavaScript, which is really about working on a large JavaScript code base as a team, and what that entails. It talks about the importance of style guides, code conventions, as well as splitting out different types of functionality and loose coupling. These are all things that are really important when working in a team to be able to work in the same codebase without stepping on each other toes. In the last section of the book is actually on tooling and putting together a build process for JavaScript where I talk about linting and testing. Basically it was the javascript ecosystem at the time that I wrote the book and how to put a build process together using ANT, which nobody uses anymore, because now everybody is using Grunt, Gulp, or Broccoli the latest build tools that are out there.

It also showed me the difficulting for writing a book for tooling in JavaScript because of how rapidly that landscape changes. which is a general problem when writing about technology anyway. When writing one of my books, I was about to finish it then Chrome was released, which is an entirely new browser. so I had to stop the presses and go back and update the entire book for Chrome. It involves a lot of deep thinking to make sure the book is still relevant by the time the book hit the presses.

You’ve kept yourself busy with Yahoo!, Box, and writing books. I read on your blog that you have been fighting with Lyme disease, can you share some of the struggles you’ve had dealing with that along with work/life balance?

It’s definitely been a struggle for a long time. I first developed symptoms in 1998, they are primarily fatigue and flu like symptoms: nausea, headaches and body aches. When it initially hit me I was sick for about a year and nobody at the time knew what it was. I wasn’t diagnosed until about two years ago. I would feel relatively normal for about two or three months, and then I would relapse again feel very ill. It comes and goes as part of the disease process. For the beginning of my career I was living a normal live and had a lot of energy. At 22 years old if you took half of my energy away due to the disease I still had a lot of energy. At the beginning of my career I got into such a bad state I was forced to take short term disability for 12 weeks, That is really hard, at a young age 23/24 years old, for your ego go through something like that. I felt like I could still do everything I needed to do. It wasn’t until I got closer to 30, I really started struggling and was sick for an extended period of time.

Once I got through that, I took a job at Yahoo! moved out to California by myself. The stress of the move across the country to an area where I didn’t know anybody caused my health to get worse.

Being caught up in this new job where I was trying to learn and adapt to a large, new company. Really, I ended up struggling with depression for the first year. For every almost everyday of that first year, I would go home after work and just cry because it felt like too much and I didn’t know how to make anything better.

There was several conversation with my Mom where she would tell me “this is just too much” and I keep saying “No, I need to make it at least one year!” that was really important to me. After one year it did start to get a little easier, work started to calm down, I felt more confident and like I actually belonged. work became my haven, it was what was holding me together. I was spending a lot of time going to doctors getting test done, and not getting anything out of that while continuing to get sick. Work became something where I could focus my attention on and I actually had control over. I found going into work as something I would look forward to because I could occupy my mind with thoughts other than how tired or sick I felt.

That started to bleed into my non-work hours because I felt too sick to go out and do something, I would stay in and think about what I had learned recently that I could write about. Writing became a great escape for me. I spent a lot of time thinking about how to optimize the way that I work.

Given that I didn’t have the energy to do absolutely everything, what are the things that I should be spending my energy on?

In that way the lyme disease help me become a better engineer, In that I stopped focusing on low impact things and started focusing on the areas that would make a big difference. As it turns out those are the traits of a good engineer.

The difference between high-performance engineers and everyone else is that they choose to spend their time on things that have a bigger impact than the other engineers do.

Once I realized that it’s a typical occurrence when you have a scare resource. You are required to find better ways to use that resource. I ended up focusing a lot of my energy on more high impact things, more books, blogs, talks and ended burning myself out.

I went through a period where I worked for myself. When you work for yourself the days all blend together and there is no end to your work day. I had to limit myself with a 9-5 work day and I got into much better habits that way. It is important not just when you are struggling with an illness, it is important as a human being to focus on other things besides coding. That allowed me to have room other things I was interested in, I got into meditating, took cooking classes, pilates, Yoga. As it turned out that was really good because the past year and a half I was too weak to leave my house and had to be able to take better care of myself by cooking healthy food and doing little exercising as I could to stay active as that is part of the healing process. The people at Box would say “Wow you are producing so much!” I was really not working 40 hrs a week, instead working between 30 – 35 hours a week based on what I could physically do. When I was working I was focusing my energy on high impact tasks so that the results of my work where a lot bigger, versus just doing every random thing that came up.

looking back, I can’t say it has been fun having Lyme disease but by having these constraints on me has been the driver that has enabled my success. Without it I can’t say that I would have been able to find the work/life balance I need or the ability to ruthlessly prioritize the things that I needed to spend my energy on.

Nicholas C. Zakas blogs regularly at http://www.nczonline.net/ and can be followed on Twitter via @slicknet. He is the author of resourceful books in the development of best practices for progressive enhancement, accessibility, performance, scalability, and maintainability.

Check out  Nicholas’ five-star rated books!

Maintainable JavaScript (O’Reilly, 2012), Professional JavaScript for Web Developers (Wrox, 2012), High Performance JavaScript (O’Reilly, 2010), and Professional Ajax (Wrox, 2007).

Read More at Interview with Nicholas C. Zakas – Front-end Engineer (Yahoo! & Box)

JSON Generator is a free web tool for building sample JSON content. You simply enter a few parameters based on custom data like avatar photos, user names, etc.

A built-in algorithm passes over the syntax to create fully-functioning custom JSON data for any web application.

The site was created by Vazha Omanashvili as a project for generating JSON code & managing custom blocks of sample data.

While the site has been online and runs perfectly, it still has a little ways to go beyond just a simple code generator. Many devs would like to see JSON Generator follow a similar path of jsFiddle or CodePen.

In fact a brand new version JSON Generator has recently been released with personal accounts, pre-built templates, custom code forking and a whole lot more. Although it’s still in beta you can test it out live to see how it fares.

Either way this can be a fantastic application for testing JSON code or just compiling sample data for a web application.

To stay on top of new releases you can follow the official Twitter account @JSONGenerator.

Read More at JSON Generator is a free webapp for Generating Data Structures

Vivus.js is the best way to bring core SVG animation to your images without building the motion into SVG files. You can setup JavaScript snippets with no dependencies as the animations all run with pure JavaScript.

You can manipulate settings like timing and certain elements of the SVG to make the animation that much more dynamic.

Here’s a snippet from the Vivus.js website:

“Vivus is a lightweight JavaScript class (with no dependencies) that allows you to animate SVGs, giving them the appearance of being drawn. There are a variety of different animations available, as well as the option to create a custom script to draw your SVG in whatever way you like.”

You can choose between a few different animation types that render the SVG into view. They’re all very interesting and super easy to setup.

To see more code snippets just visit the Vivus.js GitHub repo. It can be installed via Bower, Node Package Manger, Static Package Manager, or simply downloaded & installed directly.

Read More at Vivus.js brings SVG Animation to Life