Skip to main content

Mobomo webinars-now on demand! | learn more.

Angularjs Anyloader
At one point or another, AngularJS applications will rely on loading data. And when that moment arrives, it's nice to let your users know about it. The most common practice is some variation of a loading indicator. You’ve seen them; the spinning circle of patience, that only disappears when whatever you were waiting for finally arrives - hooray!

Any Loader To the Rescue

Wouldn’t it be great if you could add these loading indicators to your app by dropping a simple directive into your markup? At Intridea we've developed any-loader-ng, a module to easily display a loading indicator anywhere in your app. The module has two highly customizable directives for a stand-alone loading spinner (<any-loader>) and a button with multiple loading state configurations (<loader-button>). Both directives can accept a simple configuration object that determine the loading behavior. We’ve also used Font Awesome as the icon font with the default spinner icon being fa-spinner, but that can be customized.

Examples:

Here we have the <any-loader> directive in its simplest form:

Controller:

var loaderConfig = {   "isLoading": false }; 

Markup:

<any-loader cfg=”loaderConfig”></any-loader> 

By changing the controller’s loaderConfig.isLoading value to true, perhaps while you are loading some data over HTTP, it will enable the loading indicator to be displayed. There are other optional properties you can add to the configuration object to further customize the directive. The size property takes a string to change the css font-size of the icon (i.e. ‘3em’) to suit your visual needs. The iconClass property allows you to override the default icon class with whichever you choose. These customizations make the directive versatile enough for almost any app.

This time, let’s take a look at using all the optional configurations for the <loader-button> directive.

Controller:

var buttonConfig = {   "label": "Load Something",   "isLoading": false,   "isSuccess": false,   "isFail": false,   "successMsg": "Success!",   "failMsg": "Failed :(" }; 

Markup:

<loader-button cfg="buttonConfig"></loader-button> 

With this configuration, there are four separate states of the button:

  1. the default state uses the `label` as the button text
  2. the loading state uses the loading indicator as the button text
  3. the successful state uses the `successMsg` as the button text
  4. the failed state uses the `failMsg` as the button text

The button is also disabled while loading and after it finishes (regardless if it succeeds or fails).

Installing the Module

The module can be added to your project through Bower. Simply install the package using this line in your terminal:

bower install any-loader-ng --save-dev 

Once downloaded, the module requires AngularJS and Font Awesome to work properly, so be sure to have those downloaded and added to your project. To include the module to your project, just add the <bower directory>/any-loader-ng/dist/any-loader-ng.min.js file. We’ve distributed a non-minified version for development as well.

Adding the module to your AngularJS application is the same as any other module dependency:

angular.module(‘myApp’, [‘anyLoader’]); 

Go Load Stuff!

Thanks to Any Loader, there’s one less thing you have to worry about in your next AngularJS project! Check out this demo created to show off all the wonderful ways to use Any Loader.

Categories
Author

web components This article originally appeared on the Divshot blog. Divshot is a developer-focused platform for deploying modern front-end applications. It was also started with Intridea's support by Michael Bleigh!
I'm going to say something that (even in my own head) seems downright heretical. It's time to move past rigid separation of presentation and markup in web applications.

Many of us have been building things for the web long enough to remember the dark times, in the long-long-ago. Back when tables were used for layout, and the whole web looked, well, something like this.

As the web matured, we developers realized that six-deep nested tables weren't, perhaps, the best way to build things. And so began the age of the <div>. CSS allowed us to do everything (sort of, with a lot of hacky workarounds) we had done with tables, but now our markup could be gloriously free of style information. Gone were the <font> tags. Use of the style attribute became taboo, a sign of semantic weakness. And it was, if not good, at least better.

Somewhere around this time, however, a second important trend was brewing: the birth of the web application. Web sites that weren't just ways to display one's intense fandom for Doom II, but were ways to actually do things. As it turns out, browsers are quite the distribution mechanism.

Give and Take

True Fact: Square pegs do go in round holes if you hammer hard enough. That's how we used to get rounded corners.

As web applications grew more and more sophisticated, the contortions we applied using CSS to maintain semantics grew ever more bizarre. Floats within floats within relative-positioned negative-margin containers. Triple-nested <div> tags for that perfect sliding door rounded corner tab effect. The poor browsers, created to scroll top-to-bottom through a document's content, were being vigorously abused for the sake of better, more interactive applications.

Fortunately, browser standards change over time. Under the flag of HTML5 we got rounded corners, gradients, background image sizing, new tags like <section> and <header>. We even got stuff we didn't have to think about before, like media queries to make sites work on fast-growing mobile device categories. Our semantics were more semantic than ever, our buttons as glossy and round as we could ever care for them to be.

Building a proper interface or application layout, however, had scarcely gotten easier. Why is that? Because the semantics of HTML don't match those of application interfaces. Paragraphs, sections, articles, and lists are semantics that make sense in the context of a document, not an application.

Quibbling the Semantics of Semantic HTML

The document/application disconnect has given rise to frameworks like Bootstrap that provide much-desired UI widgets and layout constructs for building applications, not documents. You'll often see developers cringe at the inherent "wrongness" of "polluting" markup with Bootstrap classes. I posit that this is a reflexive and inappropriate reaction to what's really taking place.

Bootstrap, Foundation, and other similar projects are doing their best to equip developers with new semantics to describe interfaces. Interfaces are inherently visual; positioning, size, relative placement, and alignment are central semantic considerations for an interface's structure. There is no bright line between content and presentation because the presentation is the content.

Just look at modern JavaScript applications. Oftentimes the "document" content, the bit that was once central to the "semanticity" of a site, is JSON data loaded after the page loads and rendered to the interface using any of a number of client-side technologies. The HTML in these applications describes something fundamentally different from a rich text document.

Semantics are Dead, Long Live Semantics

UI and JavaScript frameworks provide stopgap measures to increase "app semanticity" in HTML, but they still function largely as hacks grafted onto an old, creaking system. Luckily for all of us, native solutions are finally beginning to arrive.

Flexbox solves many (if not most) of the fundamentally difficult aspects of building proper application layouts with HTML and CSS. It is a standard that gives us the power to do, and do it right.

Web Components offer us a real solution to the issue of app vs. content semantics. Namely, they let us define our own. If paragraphs and blockquotes don't suit your semantic requirements, how about user-profile or google-map? By freeing us from a set of predetermined tags, Web Components allow us to construct our own semantic context. They are going to change everything about how we build web applications.

The web is and will continue to be the best content distribution platform in existence. Nothing can rival its reach and simplicity. Now, after an extended awkward phase, the web seems finally ready to fight to ensure its spot as the best app distribution platform as well.

A Taste of the Future

What exactly does interface-semantic HTML look like? We can glimpse one possible future in Polymer, Google's Web Components polyfill and oh-so-much-more. It ships with a collection of layout attributes that allow developers to leverage Flexbox almost effortlessly.

Let's say I want my page to flow with a fixed header, then some content, then a footer at the bottom. Using layout attributes, it looks like this:

<body fullbleed vertical layout>   <header>My Header content here</header>   <section flex id="main">My main content</section>   <footer> </body> 

With no custom CSS and a declarative syntax that reads almost like English, the layout attributes offer simple semantics with a kind of "it just works" magic to them. Memorize a few keywords and you can build complex application layouts just about as fast as you can type.

I don't know whether Polymer's layout attributes are the best way forward. What I do know is that using them feels natural, almost addictive. HTML is remarkable for its ability to be declarative and compositional. Polymer offers one potential solution, but the biggest potential lies in the ability of developers everywhere to strike out in new directions, ignoring the constraints of the past. We're going to make some mistakes, we're going to take things too far; that's how progress is made!

What to Take Away

When building applications (as opposed to authoring documents), the structure of HTML should be judged not on how closely it adheres to semantics of content but to those of interface. Don't sacrifice the future on the altar of semantic purity. The next time that vein in your forehead starts throbbing at some "non-semantic" HTML, ask yourself: what are the true semantics at play?

It's early days for the next HTML revolution. I strongly encourage everyone to start learning, start experimenting, and start questioning the status quo. The best practices of the future haven't been discovered yet. Now's your chance to play a part in writing them. My suggestions:

  1. Play with Web Components. The Polymer site is probably the most comprehensive starting point for practical use today.
  2. Challenge your assumptions. Pretend you aren't scarred by years of battling HTML. What would your HTML look like if you defined the semantics?
  3. Share your results! No one has invented the best way to do just about anything with Web Components yet. The more people there are thinking, doing, and sharing, the faster we'll discover those as a community.

Let's all go forth and define the semantics of a new generation. The web platform, despite being more than 20 years old, is still in its infancy.

Update: Let's NOT Kill Accessibility

As was pointed out in the comments, many users of the web have needs other than just looking at things and clicking on them. This post was aimed at the dogmatism of "pure" markup and was in no way intended to encourage making the web less accessible. Here are a couple great links about keeping accessibility while building Web Components:

Thanks to @stommepoes, @aardrian, and @marcysutton for pointing out the omission and supplying the links! We should remember that putting users first isn't just a good idea, it's the standard!

Any questions, thoughts, ideas? Send 'em our way!

Categories
Author

Angularjs

 

Advanced Tools

Once you’ve mastered the layer of preprocessors and JavaScript frameworks (see part one for more info), you’ll be ready to take a look at some advanced UI development tools. In fact, you may have encountered any of these, to some degree, as you start working on larger web projects and applications.

Package Managers (prereq: Terminal)

As the number of dependencies in a project increases, it becomes increasingly important for developers to have ways to manage the download, inclusion, and versioning of an ever increasing number of dependencies. Package managers aim to solve this task by automating some or all of the tasks associated with managing the various assets and dependencies that may be included in any project you find yourself working on.

CodeKit is a GUI for searching for project dependencies (like jQuery, or Bootstrap), downloading those to your project folder, and managing the versioning/updates of the dependencies. CodeKit also includes a web server tool that allows you to host your project files locally without having to setup your own local web server, as well as tools to automate compilation of your Sass, CoffeeScript, etc. Neat.

Bower and NPM are command line tools that offer similar functionality. After being installed, you can download any asset from the Bower repository by running the bower install command. It also allows you to specify which versions of assets you’d like to use in your project, and automatically updates them all every time you run bower install. In this way, if one developer on your team makes an update to the version of jQuery you’ve included in your project, then checks that change into your shared repository, all other developers on the team can ensure consistency by simply updating their code base and then running bower install. CodeKit comes with Bower built-in, so you can install Bower packages directly from the CodeKit UI.

NPM (Node Package Manager) is a package manager that’s part of Node.js. Bower is actually a Node package, so after installing NPM, you can install Bower by simply running npm install bower. In addition to Bower, you can use NPM to install a plethora of assets (120,151 at the time of this writing), including tools I’ve already mentioned (Sass, CoffeeScript, Cordova) and have yet to mention (Grunt, Gulp, Browserify).

Bower and NPM may seem similar, but one of the biggest differences is that NPM handles nested dependencies (meaning dependencies can have dependencies), while Bower is a flat dependency tree (meaning that the user must resolve the dependencies; they’re not resolved automatically).

Browser Refreshing (prereq: Terminal)

In the olden days, to develop a website, you’d edit an HTML file, and refresh your browser to see the changes. With HTML, CSS and JS all being compiled in modern apps, it adds another layer. You’d have to save your source file (.sass, or .coffee, for example), compile it to CSS or JS, respectively, and then refresh your browser to see the changes. Browser refreshing tools allow developers to automate the refresh of the browser window when changes are saved to a source file.

Whether you’re using the LiveReload GUI or the command line tool Guard, you’ll need to install the LiveReload Chrome extension. This allows the browser to watch the underlying files for the page you’re viewing, and refreshes the browser window for you (without a noticeable full page refresh). For managing the process of watching source files and compiling them, you have three options: the LiveReload GUI, Guard, or Grunt.

Task Runners (prereq: JS, Terminal)

If you’re familiar with both JavaScript and the command line, having a look at task runners is a good idea. Even if you’re not, Chris Coyier has a great post titled Grunt for People Who Think Things like Grunt are Weird and Hard. Task runners allow web developers to automate an almost infinite number of tasks, like the aforementioned Sass and CoffeeScript compilation, concatenating a number of small JS files into a larger one for production, or compressing image files.

Gulp is the new kid on the block when it comes to task runners, but is very popular, and I’ve seen it used in many projects recently. Neither Grunt nor Gulp have GUIs, so you have to be proficient in JavaScript in order to use them. Their syntax is 100% JavaScript, so a healthy understanding of JS will go a long way here.

Testing (prereq: JS)

With the migration of many development methodologies typically exhibited on the backend into the front-end space in recent years, its no surprise that testing has come along for the ride. Testing in modern web apps has roots in writing tests for desktop applications, where the code would be compiled and packaged for production prior to being available to the public. Writing tests in JavaScript is mainly included in large scale projects, which use one of the JavaScript frameworks mentioned earlier. Generally, an app will have a combination of unit, integration, and e2e (shorthand for end-to-end) tests.

Karma is a unit test runner that will find all the unit tests you’ve written, open a browser, and run the tests in them. Its not partial to the framework the tests are written in; that is, you could write tests in Jasmine, or another testing framework, like Mocha, and Karma will run them. Jasmine is a testing framework, which is the actual syntax you write your tests in. Karma and Jasmine are the preferred method of testing AngularJS apps.

While unit tests are designed to test individual pieces of functionality, e2e tests are designed to test the entirety of your application. It’s truly amazing to watch Protractor fire up Chrome and perform every action you’ve defined in your tests. Protractor is the tool of choice for writing e2e tests for AngularJS.

Front-end Ops (prereq: JS)

Front-end Ops is new subset of front-end development that focus solely on the performance, builds & deployment, and general stability of modern web apps. The term was coined in an article in Smashing Magazine by Alex Sexton. As the front-end has increased in complexity, so too has the need for individuals solely focused on maintaining the health of the front-end.

Two tools used by front-end developers focusing on operations are RequireJS and Browserify. RequireJS is a tool for modularizing your JavaScript and CSS files, and optimizing them for deployment by minifying them, or removing comments, etc. AngularJS has dependency injection built in, so there’s no real requirement for RequireJS, and you can also handle a lot of the optimization with tools like Grunt. Browserify is much newer than RequireJS, and I honestly haven’t spent that much time with it yet, but I expect to start seeing it on a lot more projects.

It should be noted that these tools will eventually be phased out by the inclusion of module definition/injection in native JavaScript as part of the ES6 (ECMAScript 6) spec. They’ll be around for a while, and are currently in heavy use, but its worth keeping this in mind.

Looking Forward

Once you have mastery of many of the tools and technologies mentioned in this post, you’ll be ready for what’s coming down the modern web development pipeline: web components.

Web components are the future of how websites and web apps will be built. Web components allow modules or components to be truly independent, where the HTML, CSS and JS for each component is applied solely for that component, with no risk of conflicting with other components in the same site or app.

Polymer is a Google project that aims to make web components available today, so once you’re comfortable, start experimenting.

Hopefully this post has given you a good idea of the pieces that make up the modern front-end developer’s toolset. It may seem like a lot at first, but having a reference like this is a great place to start. If you get started today, you’ll be amazed at what you can create!

Any questions, thoughts, ideas? Send 'em our way!

Can't get enough? Well here you go!

  • An Introduction to Front-End Developer Tools
  • SEO for Single Page Applications
Categories
Author

javascript

The tech stack for front-end web development has expanded vastly in recent years. For veterans of the industry, the progression has been gradual, however for folks just starting out, these changes may not be the easiest to digest. Thus, I compiled a list of front-end tools I use on a daily basis along with the steps I’d take as a newbie to the industry.

The Basics

  • Core Tech
  • HTML
  • CSS
  • JavaScript
  • Terminal
  • Chrome DevTools

The foundational technologies that make up any website are HTML, CSS and JavaScript. If you’re just starting out, the Web Platform Docs and the Mozilla Developer Network are good places to look. While there’s a lot to learn with core HTML, CSS and JavaScript, a solid understanding of the basics is required, and as we’ll see in a bit, many modern tools are layered on top of these foundational technologies.

Additionally, many of the modern tools used in front-end development rely on a basic working knowledge of the command line, which on OS X is Terminal. Pluralsight has a great video by Dan Benjamin that introduces the basics of the command line. Again, its not necessary to become a command line pro to be a front-end developer, but a basic understanding of how to move around, create files & folders, and familiarity with the following will get you further than most: grep, ssh, find, curl, git, npm.

Finally, as a front-end developer, you need some way to inspect the generated HTML markup, CSS styles, and JavaScript that make up any web page you’re working on. The standard for modern web developers are the Chrome DevTools, and CodeSchool has a great course covering what you can accomplish. One item to note here: most modern websites modify the HTML markup using JavaScript. This means the text you see in your source HTML file may differ when you inspect it using the “Elements” tab in Chrome DevTools. This is a concept I became very familiar with while working with jQuery Mobile years ago (and playing with jQuery Mobile may still be a very effective tool for this purpose), but its also something you’ll encounter as you start working with some of the additional tools below.

UI (User Interface) Frameworks:

When you build websites every day, you’ll start to notice some patterns emerging in the projects you’re involved with. Components like navigation bars, buttons and labels, and pagination are all common patterns you’ll likely find yourself repeating over and over. UI frameworks are an attempt to abstract the common elements into reusable modules, so web developers can have a base starting point for the various elements used in their sites or apps.

The most popular of these, by far, is Bootstrap. Bootstrap allows you to rapidly build responsive user interfaces, and as a result is very popular both as a prototyping tool and as a production framework. The Bootstrap docs are organized such that you can become familiar with the basic CSS, progress to CSS components, and move on to the more advanced JavaScript components when you’re comfortable. It’s also worth noting that with some Bootstrap components, you’ll see generated markup that I mentioned in the previous section.

There are many more UI frameworks out there (Semantic UI, Foundation, ChocolateChip-UI, Topcoat, etc.), but one that’s really picking up steam currently is Ionic. Ionic is a mobile UI framework, focused on building iOS and Android apps using Cordova to wrap HTML code as a native app, and uses AngularJS (which we’ll get to shortly) as its JavaScript framework. We’re getting a bit ahead of ourselves, but suffice to say that if you want to build an app for iOS or Android using web technology, and learn AngularJS in the process, there’s no better way than spending some time with Ionic.

Version Control (prereq: Terminal):

You’ll want to keep a record of the work you do, and probably collaborate with other developers. Version control, or source control management, is a way you can incrementally save versions of the file or files you’re working on, and leave notes in the process, which, when grouped together, is called a commit. When you commit the code you’ve been working on it creates a version of that code locally which you can then compare at a later time to remind yourself what changes you made and when you made them. Git and Mercurial are two popular command line tools that serve this purpose. If you’re not comfortable on the command line, there are a variety of GUI applications available like GitHub’s, GitX, Git Tower, and SourceTree.

Taking this one step further, if you want to work on the same code with other developers, you can push your commits to a communal server, where everyone can access your changes. Enter GitHub. GitHub allows you to share your code with other developers, and pull down the work other developers have completed, and merge it with your changes. Overall, version control offers a very visual way to compare your work with the work of other developers, and as such is a great collaboration tool. CodeSchool has a great free course called Try Git, if you’re just getting started.

The Next Layer

Once you’ve covered the basics, there’s another layer of tools that sits on top of foundational web tools. Each of these tools requires a prerequisite understanding of the underlying technology.

Templating Languages (prereq: HTML):

HTML templating languages are an abstraction of common HTML. They exist to make writing HTML less repetitive, less error prone, and more rapid. They require an understanding of compiling the code you’re writing, which means the end result will look very different than the source code you’re editing. Both Handlebars and HAML compile to HTML.

Handlebars is most frequently paired with Backbone, and used in place of standard HTML files in Backbone applications. Rather than writing static HTML, web developers write small chunks of markup in standalone Handlebars files, that can be reused in various locations throughout a single application. Handlebars pairs nicely with Backbone as it gives developers access to data directly in the HTML markup, so you end up writing less JavaScript to get the same result.

HAML is frequently found in Ruby on Rails applications, and is a shorthand method of writing HTML that integrates directly with Ruby code. The driving factor behind HAML is that Ruby’s ERB syntax, like PHP, requires the author to “pop” in and out between writing HTML, and writing markup that will be generated by Ruby. This can lead to code that’s very difficult to read. HAML solves this issue by allowing the author to generate HTML markup without any of the repetitive angle brackets seen in both HTML and ERB.

CSS Preprocessors (prereq: CSS):

Like HTML templating languages, CSS preprocessors allow you to both write code that is compiled, and require a healthy understanding of the underlying language you’re writing (in this case, CSS). They’re very powerful, allowing web developers to write less code, reuse portions of code to decrease repetition (something very common in CSS), and modularize your CSS so you can benefit from conditionally loading CSS rules only when needed. The two most popular CSS preprocessors are Sass and Less.

Sass is an incredibly powerful language that allows developers to introduce more complex programming techniques to CSS, like variables, nesting, and mixins. Sass (and Less) have gained in popularity as the backend techniques of writing object-oriented code have migrated to the front-end. You may have heard of object-oriented CSS, and Sass is a great starting point for learning how to do some really powerful things with CSS. CodeSchool has a great introduction to Sass called Assembling Sass.

Less is an alternative to Sass, but is very similar. Basically, if you understand Sass, you’ll understand Less. There are syntactical differences, but the principles remain the same. Less is what’s used in the Twitter Bootstrap project (mentioned earlier), and as the CSS preprocessor of choice for the most popular UI framework on the planet, has become very popular itself.

JavaScript Preprocessors (prereq: JS):

Rounding out our trilogy of front-end preprocessor categories, CoffeeScript is very similar in that you write CoffeeScript, which then compiles to JavaScript. CoffeeScript is the brainchild of Jeremy Ashkenas, the author of Backbone and Underscore. The goal of CoffeeScript is to allow developers to write JavaScript that reads more like natural language, resulting in source code is very easy to read and understand. What’s actually served to the browser is vanilla JavaScript that can be very difficult to read, though more optimized for performance in a browser (also referred to as being “machine readable”).

The CoffeeScript docs are a great place to start, but there are many free and paid resources available to learn the language, like the CoffeeScript Cookbook, The Little Book on CoffeeScript, Smooth CoffeeScript, Meet CoffeeScript, A Sip of CoffeeScript, or the CoffeeScript Basics RailsCast. Of course, they all require a very good understanding of core JavaScript, so make sure you have a good grounding in the foundational language.

JavaScript Frameworks (prereq: JS):

JavaScript frameworks abstract a lot of the functionality typically left to developers to solve on their own. In the case of jQuery, its main purpose is to allow web developers to focus on the functionality they’re building, and not get distracted with browser inconsistencies with regard to JavaScript. jQuery also abstracts common JavaScript patterns, the most common of which is AJAX (short for Asynchronous JavaScript and XML). jQuery probably should be earlier in the learning stack, but an understanding of it is required to some degree in order to use portions of both AngularJS and Backbone, so I grouped it here.

Backbone and AngularJS are two of the more popular MVC or MV* JavaScript frameworks used in production today. A solid understanding of JavaScript is recommended before diving into JavaScript frameworks. They both allow developers to rapidly produce single-page applications (SPAs), albeit in very different manners. Backbone covers a core set of basic functionality and then gets out of your way, while AngularJS is more robust and opinionated.

Taking the example of AJAX, you have to first understand what AJAX is (The best guy at explaining AJAX is Jeremy Keith, hands down), then understand how the jQuery.ajax function works, in order to understand how the implementations in Backbone (Backbone.sync) and AngularJS ($http) work.

Some resources I’ve found very helpful in getting up to speed with Backbone and AngularJS include The Anatomy of Backbone.JS, Backbone.Marionette: A Gentle Introduction, AngularJS: Up and Running, Shaping Up with AngularJS and A Better Way to Learn AngularJS.

Ready to dig deeper?

Check back next Tuesday for an Intro to Advanced Front-End Developer Tools. In the meantime, let us know what you think! Any questions, thoughts, ideas? Send 'em our way!

Can't get enough? Well here you go!

  • Sass Functions: Play and Profit
  • SEO for Single Page Applications
Categories
Author

Mobomo was thrilled to partake in Collaborate, a Fosterly-sponsored forum for startup innovation. Dubbed "The Innovator's Conference", Collaborate brought innovators from all over the region—and even the country—to the Ronald Reagan Building and International Trade Center to engage in endless collaboration and learning.

 The two-day event provided tech entrepreneurs, digital strategists, and leaders from federal and private organizations an opportunity to explore topics such as getting the public sector to embrace digital solutions, and how to think like a data scientist. Those just beginning their startup journey and others well along the path swapped fresh ideas and hard-won best practices. Google X, Facebook, NASA, and Twitter even joined the valuable exchange, and a glittering roster of successful thought leaders facilitated workshops and roundtables.

We were happy to join Verizon at Collaborate, and were excited by both the stream of groundbreaking ideas and the overwhelming sense of community at the conference. Looking forward to the next one, Fosterly!

Categories
Tags
Author

Pay it Forward

 

Always be a student…

My first official ‘lesson’ in web development was a six week beginner’s Javascript class. It was offered by the Columbus chapter of Girl Develop It or GDI. I didn’t know it when I signed up, but this would be the springboard for my career.

Honestly, I didn’t retain much of the knowledge presented in those six weeks. I was as green as could be to the programming world. Most of the information sailed right over my head but I did gain something incredibly valuable from attending: the spark to learn more. I wanted to understand, why I didn’t understand. I was hooked.

Teach to Learn

After a year of sharpening my skills and making the leap into full-time web development, I was approached by GDI to TA for the beginner/intermediate HTML/CSS courses.

Talk about feeling extremely under qualified! How was I supposed to stand in front of a group of students and tell them how things should be? What if I didn’t have the answers or steered them in the wrong direction?

After several internal debates and a bit of pressuring though, I decided to give it a go. Not only were my fears terribly off, but teaming up with Columbus’ GDI community was one of my best decisions. Getting to ignite, hone, and nurture students is a pretty great feeling. I never thought I was capable of helping folks in such a significant way. Seeing a student go from overwhelmed and confused to confident in their skills is something everyone should experience.

Since my first course, I’ve assisted five additional semesters and its only gotten better. Now, it’s not just about teaching the curriculum, it’s about finding better, more efficient ways to present the information. As a teacher, the planning and prep has not only helped to sharpen my own skills, but its kept me in the student mindset; always looking for ways to make web development approachable and fun.

Give back

Girl Develop It is an international organization providing affordable and accessible programs to women who want to learn software development through mentorship and hands-on instruction. Although their focus is getting women into tech, they also welcome men to attend classes as well. GDI has chapters all across the USA. And, if they don’t already have a chapter in your town, GDI will help you get a chapter started in your area.

GDI holds all types of events throughout the year. Ranging anywhere from the aforementioned beginner HTML/CSS and javascript classes to more advanced classes, meet ups and social events.

Want to give back and hone your skills in web development? Hit them up and see if you can help!

Categories
Author

angularjs

AngularJS and web forms are a match made in heaven. AngularJS version 1.3 has made it easier than ever for developers to build powerful, user-friendly, and maintainable web forms. Users have certain expectations when confronted with web forms and developers should anticipate these expectations. Therefore, removing any and all obstacles between the user and a completed, valid form is of upmost importance!

Validation

Isn’t it annoying when you fill out a form, hit submit, wait, then the page jumps to the top with some cryptic red text telling you how bad you are at filling out forms? Users hate that. Everyone hates that! Let’s empathize with our users and create a form the sets them up for success.

Enter front-end validation. With the 1.3 release, the Angular JS team bestowed onto us the ng-messages module. This is a tremendous improvement in how we build validation into forms. The module allows developers to have a list of generic error messages for common validation errors as well as craft custom messages for those more complex field types.

Here’s how I use the ng-messages module on a form field:

<div class="error-message"   ng-messages="loginForm.email.$error"   ng-if="loginForm.email.$dirty"   ng-messages-include="views/widgets/formErrors.html"> </div> 

Let’s break down the different directives used here. First, the ng-messages directive on the <div> refers to the error object for the field you are validating. The module will detect any properties on the $error object and display the appropriate error template. Next, is the ng-messages-include directive. This references a template for all of my generic error messages (required, min-length, max-length, etc.). Using a template for these common errors allows very easy maintenance and consistency throughout the application.

Example of a generic message in the formErrors.html template:

<div ng-message="required">This field is required.</div> 

For custom validators, just replace the “required” value with the name of the validator (ex: “pattern”).

Also, the ng-if directive set to the field’s $dirty flag allows us to hide the validation messages ‘till the user enters something into the field. Thus, preventing the form from displaying a bunch of “errors” upon first load.

Expectations

Users expect most forms to work the exact same way on the web. If the user has to spend unnecessary time figuring out how to fill out your form, it builds resentment and frustration; damaging the trust between you and your users. Keep the form consistent and make a point to ensure simple tasks are done right! For example, the “submit” button.

Hitting enter should submit the form. This sounds simple enough, but it’s very easy to overlook. Developers often attach the ng-click directive to a button, point it to a function to submit the form data and call it a day. Without using the ng-submit directive on the form tag, hitting enter won’t do anything to your form. This is especially important on small, short forms like search or sign up because the user is just expecting to submit using the enter key.

Here’s what that form might look like:

<form ng-submit="vm.submitForm()">   <label for="name">Username:</label>   <input type="text" name="username" id="username" ng-model="vm.name" />   <label for="password">Password:</label>   <input type="text" name="password" id="password" ng-model="vm.password" />   <button type="submit">Submit</button> </form> 

Maintenance

Coding forms can be very repetitive, especially when we include the markup for validation. Creating templates for commonly used fields and markup can definitely help keep your code DRY (Don’t Repeat Yourself). You could even go so far as to creating directives for each type of field or form component. Well, I have good news for you. Someone has already done just that: https://github.com/formly-js/angular-formly. This module allows you to keep templates for each type of field and dynamically generate forms using a JSON object. If you’re interested in easily generating forms throughout your application and keeping all forms consistent, angular-formly may save you a ton of time.

Empathy

Following these easy patterns will keep your users happy clicking and tapping through your application. Let’s face it, forms aren’t the most exciting feature, but they are necessary. Why not make them quick and easy and move on to those more awesome features you have to offer?

Want to dig deeper? Check out my codepen to see some of the patterns we discussed in action.

Categories
Author

At Intridea, we enjoy helping our customers create secure and functional marketplaces. From investigating and research to testing out the product, finding the best payment solution for our client is top priority.

Recently when looking for a replacement ACH payment processor we had an opportunity to do a deep dive into Dwolla and were pleasantly surprised! We worked through an initial integration with one of our Rails apps, and in this post I'll share how you can do the same.

What is Dwolla?

According to their site:

Dwolla is a payment network that allows any business or person to send, request, and accept money. Unlike the big payment companies that rely on plastic cards and charge hefty fees, Dwolla built their own network that securely connects to your bank account and allows you to move money…

We chose to go with their OAuth + REST API method for integration, but this was one of many possible scenarios. Not only does Dwolla have multiple options for connecting and delivering payment requests, but (as is attractive to any developer) their documentation is clear and concise.

One aspect we’ve avoided in the past with systems like Dwolla, is forcing users to create full accounts prior to gaining access. Dwolla’s new “direct” offering allows users to proceed with an email address, password, and their bank’s website credentials only; saving time, effort and eliminating errors. You can see an example of their form builder here.

Connecting Dwolla to your rails app

Hundreds of people are leveraging the advantages of super simple, secure authentication with OmniAuth in their applications. This authentication route helps simplify login and allows you necessary access to Dwolla permissions.

First, let's add the two gems in your Gemfile. Note: If you want to handle payments as well as incoming funds, add dwolla-ruby too.

gem 'omniauth-dwolla' gem 'dwolla-ruby'  

Next, configure omniauth-dwolla by adding the middleware to config/initializers/omniauth.rb and getting a token with scope permissions for full user info access and sending and requesting transactions:

Rails.application.config.middleware.use OmniAuth::Builder do   provider :dwolla, ENV['DWOLLA_KEY'], ENV['DWOLLA_SECRET'],    :scope => 'accountinfofull|send|request',   :client_options => {         :site => 'https://uat.dwolla.com',         :authorize_url => '/oauth/v2/authenticate',         :token_url => '/oauth/v2/token'       } end 

Finally, visit https://uat.dwolla.com (Dwolla's sandbox which mirrors production) to create a testing account. The sandbox is full-featured, with everything you need in testing; transactions, activity logs, adding funds to test accounts, etc. Once you’ve registered for this test account, you’ll be able to retrieve user information from the Dwolla site when users create an account on the marketplace app. See below:

    "raw_info": {         "City": "New York",         "Id": "123-456-7890",         "Latitude": 41.584546,         "Longitude": -93.634167,         "Name": "Test User",         "State": "NY",         "Type": "Personal"     } 

Before we play with some functions, let's set the secret and key for the app, located in your registered application panel. Remember to record your pin (shown below) for your reference. The pin ensures security for purchases both from your application and for individual purchasers.

# Dwolla Secret Stuff @api_key = 'ztRqeAYvw0B6KFezOuw161bbxWdrmEDPbWVWgETN086Mmj809y' @api_secret = 'knZgUVDlmqWLcao2e64xU+X/L+YMMMaeZQz8JjcFyA+aQgtyXt' @token = 'Bx3bmKWClyUZdLi3KnnQwXkAcOtJy7c/qAzV6oNaHdB0nXobCC' @pin = '1234' 

Using the Dwolla API

You should initiate a new Dwolla User client and seed a previously generated access token (see below) every time you want to call the API.

Dwolla::token = @token Dwolla::api_key = @api_key Dwolla::api_secret = @api_secret 

In order to handle transactions (you can try in rails console):

##### Send money ($1.00) to a Dwolla ID transactionId = Dwolla::Transactions.send({:destinationId => '812-626-8794', :amount => 1.00, :pin => @pin})  ##### Send money ($1.00) to an email address, with a note transactionId = Dwolla::Transactions.send({:destinationId => '812-626-8794', :destinationType => 'Email', :amount => 1.00, :pin => @pin, :notes => 'Everyone loves getting money'})  ##### Get details about a certain Transaction pp Dwolla::Transactions.get(transactionId)  

Handle funding sources.

Keep in mind, as the seller you can affect funding sources in Dwolla's admin panel. We've found that you often need this to let the buyer update/add their bank information to Dwolla via your marketplace.

##### Fetch detailed information for the funding source with a specific ID pp Dwolla::FundingSources.get('some_funding_source_id')  ##### Deposit funds from a bank account into the Dwolla account balance. pp Dwolla::FundingSources.deposit('some_funding_source_id', {:amount => 30.05, :pin => @pin})  ##### Withdraw funds from a Dwolla account balance into bank account pp Dwolla::FundingSources.withdraw('some_funding_source_id', {:amount => 30.05, :pin => @pin})  ##### Add a new bank account. Possible values for account_type: "Checking" and "Savings" pp Dwolla::FundingSources.add({:routing_number => 1111111, :account_number => 1111111, :account_type => "Checking", :name => "Owner Name"})  

There are a multitude of ways to interact with the Dwolla API, and their documentation breaks it down for both developers and non-developers. There are tons more samples like I posted above, but what's more important is to apply the functions correctly to your marketplace use case. Additional features can be found in their labs, click here for more surprises.

If you are looking for a payment gateway, I strongly recommend you use Dwolla. From all angles, it's a complete and smoothly implemented choice. Got any questions? Let us know!

Categories
Author

dear maggie
Dear Maggie,

As a parent, working from home is such a blessing! Getting to send them off to school, attend midday field trips, and being home when they return is a privilege I'll never take for granted.

The only struggle though, is balancing work and family time when the kids are on vacation. I always seem to spend the entire day trying to placate one of them, and no matter how hard I try, the interruptions always equate to less work during the day and more in my evenings.

And of course, this doesn’t help with the reports of “Dad works all the time!” and only furthers their desire to have more of my time the next day. Any tips for making these days more enjoyable for everyone?

Run Ragged in Reno


Hey Ragged,

While I don’t have any rugrats of my own, I do have a total of 7 make that 8, nieces and nephews. Whenever I work from my brother’s house and the munchkins are around, my productivity is completely shot. I spoke with a few expert Intrideans though, Ben and Jeff, who manage being great dads and productive workers, and we’ve come up with a few surefire tips for gettin’ er done when the kiddos are around:

1. Tell them “bye” in the morning.

You may just be going into your office, but we’d still recommend telling your kids “bye” in the morning. It doesn’t have to be any more grandiose than a quick hug and a kiss for their day. Sure, you’ll probably see them again in five minutes for a coffee refill, but it creates a clean break and lets them know “you’re now at work.”

2. Create boundaries.

The best way to get work done with little ones around is to have your own space. Many people will create a hanging sign for their office door, indicating they are or are not available. Others create a system of their door being open or cracked. Whatever your method is, establish clear boundaries that your children can understand.

3. Ask for quiet when you need it.

Everyone knows kids are GREAT at making noise. Between general mirth or tears and the toys and TV, things can get loud. Usually just a quick “Hey, hoping on a call” is all it takes to keep them happy and quiet for the duration (so long as you’ve explained what that means, and they have engaging quiet activities for them). It’s important to follow up if expectations aren’t met, and you should be ready for it to take a little while to get it just right.

4. Expect the unexpected.

You never know what you might walk into when you leave your office, and trying to plan or expect too much will lead to disappointment. Accept that you’re raising kids (not robots) and it is their house as well. Do your best to come to terms with the ups and downs, and remember they’re only this little once, so don’t let the mess affect the time you have with them.

5. Make time for visits.

All the above might make it sound like you should try to be distant from your kids during the day, but it’s quite the opposite. You should do your best to make time and visit with them for small blocks of time every day. Try having lunch with your family, play a game, or go for a walk with them. It’s the simple things kids remember most and working from home is the perfect opportunity to create those memories.


Got an idea for our next post? Send your burning questions, feedback, or suggestions over to dearmaggie@intridea.com! We'd love to hear from you.

Also, check out Dear Maggie's advice on relationships and working remotely.

Categories
Author

DorkLooking dorky and non-utilitarian. Photo by Teresa Bouza, Americas DataFest

Google Glass failed not because it was dorky (it was), but because it sucked. Utility drives fashion, and had people found Glass useful enough they would have worn it regardless of how they looked.

The best analogy is the transition from the pocket watch to the wrist watch: in the late 1800s soldiers discovered they could coordinate maneuvers more efficiently if their watches were strapped to their wrists instead of buried in their pockets. Only later did technology and miniaturization allow the wrist watch to become fashionable.

Basically: Dorky White European Guys Willing to Look Silly to Get Stuff Done™.

Two centuries later Google Project Glass debuted without much stuff to be done. All of the dork, none of the utility.

I was a Glass Explorer and we had fun at Intridea playing with the technology, but it’s an object lesson in the need to delight—or at least be useful.

Categories
Author
Subscribe to General