UMBC is a community that gives. Nearly each day in the breezeway next to The Commons, one might stroll by multiple tables occupied by students raising money for this charity or that. Our faculty and staff give annually in support of UMBC and organizations supported through the Maryland Charities Campaign. And, of course, alumni dedication to UMBC spans decades — starting with the first graduating class, in fact.

In a guest post on UMBC’s Breaking Ground blog, UMBC archivist Lindsey Loeper ’04, American studies, recently uncovered evidence of a truly momentous philanthropic action made by the Class of 1970:

The first senior project that I can locate in UMBC’s history is from 1970. The class of 1970 is often referred to as the Founding Class, because the graduates were the first group to complete all four years of their degree at UMBC. As in the origin stories of many of our campus traditions, UMBC students decided to forge their own path. During the Spring 1970 semester, a group of seniors organized to collect donations from the UMBC community as well as area businesses. Their goal was to establish a campus fund to assist students that were having trouble paying their full tuition bill.

According to the 1970 edition of Skipjack, the early UMBC student yearbook, the final total collected was $13,000, which is equivalent to more $75,000 today! For in-state students in 1970, a year of tuition at UMBC cost just $506, so a $13,000 emergency fund would have helped quite a few of them continue taking classes and working toward their degrees.

We’re so happy to see the celebration of student philanthropy on the Breaking Ground site not only because it was a truly generous moment shared by the Class of 1970, but because it signifies a spirit of giving that continues to live in our current students. And, it serves as an excellent segue to a new initiative that will be launched soon to help current students use the most modern online techniques to raise money for UMBC-based projects. Stay tuned for more on that!

Meanwhile, please enjoy Lindsey’s full post here.

In my previous tutorial, I touched on how to use Ember.Object to define your models and work with datasets. In this section, we’ll look more closely at how Ember uses the Handlebars templating framework to define your app's user interface.

Client-side Templates

Most server-side developers are used to using templates to define markup that will be dynamically filled on the fly. If you've ever used ASP.NET, ColdFusion, PHP or Rails then it's pretty much assured you know what I'm talking about.

JavaScript Client-side templating has really taken off of late especially because of the focus on building more desktop-like experiences. This means that more of the processing is done on the client-side with data being mainly pulled via server-side API requests.

I remember writing about client-side templates some time ago when the jQuery Template plugin was first released. Nearly three years later, it's still the most read post on my blog, showing how interest in client-side templating has risen. Since then, a number of other frameworks have been released, offering rich features and supportive communities. Handlebars is one of the more popular options and the framework chosen by the Ember project to power it's templating needs. This makes sense as Handlerbars was created by Ember.js co-founder and core team member, Yehuda Katz. Note, though, that I'm not planning on doing comparisons between templating frameworks and I will strictly focus on Handelbars since this is what Ember.js uses by default.

In the previous articles, I showed some very basic templates in the code:

<script type="text/x-handlebars">
        <h2><strong>{{firstName}} {{lastName}}</strong></h2>
    </script>
    

Two things that stand out are the type declaration for the script tag and the curly braces which act as delimiters for the expressions that Handlebars will act upon. This is very typical syntax that I'll discuss in more detail soon and you'll use consistently as you build Ember templates.

The Syntax

Despite the fact that Handlebars uses a special syntax, at the end of the day, you're really working primarily with standard HTML markup. Handlebars serves to inject content into this markup to render data to the user. It does this by parsing the delimited expressions and replacing them with the data you've asked Handlebars to work with. In the case of Ember, Handlebars provides the hooks and Ember uses them. That data typically comes from your controller (remember that controllers serve as the interface to your models).

The first thing any template needs is a script tag definition. Most of you have probably defined script tags to load your JavaScript library. In fact, you've already done this to load Handlebars into your Ember project:

<script src="js/libs/jquery-1.9.1.js"></script>
    <script src="js/libs/handlebars-1.0.0-rc.3.js"></script>
    <script src="js/libs/ember-1.0.0-rc.1.js"></script>
    <script src="js/app.js"></script>
    

There's a slight difference with using it to define a template. First, we're specifying a type attribute of "text/x-handlebars". This type is ignored by the browser but leaves the text available for inspection and allows Ember to identify templates within the app. In addition, Ember uses a data attribute called "data-template-name" which Ember can use to associate specific parts of your application with a template. For example, the following declaration defines a template with a name "employee":

<script type="text/x-handlebars" data-template-name="employee">
    ...
    </script>
    

When your application starts, Ember scans the DOM for type="text/x-handlebars, compiles the templates it finds, and stores them in a property of the Ember object, called Ember.TEMPLATES which it uses to figure out what to render for a given route. This is why following Ember's naming conventions is so important. In the example above, this template will be automatically associated to the employee route and controller you created in your application. Again, I can't stress enough how these naming conventions will make your development much easier.

Ember is reliant on URLs to determine the resources that need to be used and the templates that need to be rendered. Let's imagine that you had a profile page with the URL "/profile". You would have a resource, called profile that would load specific resources for that URL (like a route object) and you would also have a template by the same name. We reviewed defining resources and route objects in part 2 of my Ember series so if you're not sure about what I'm discussing, be sure to hop back there to refresh yourself on this.

When you visit that URL, Ember knows it needs to load these resources and parse the template you've defined. It does this via its naming conventions, knowing that because you went to "/profile" it needs to load the resources defined in the profile, and render the template, named data-template-name="profile".

• Route: ProfileRoute
• Controller: ProfileController
• Template: profile (note that it's lowercase)

Going over the naming conventions again, you'll see that the route, controller and template are all tied together using the same URL name with the exception that the template is spelled in lowercase. This is what allows Ember to manage everything behind the scenes without you having to do a lot of wiring up.

Also important to note is that, if you declare a template without a data-template-name attribute, Ember will assume that it is the Application-scoped template – the one typically used as a site-wide template for creating user interface elements, such as headers, footers and navigation. And if you don't explicitly define a template for an application or even a resource (e.g: for a URL), Ember does that automatically for you to ensure stability and consistency in your app.

Expressions

The next step is to include your markup and the delimited expressions you'll be using to represent your data. Expressions are delimited, via double curly braces which allow them to be easily identified and parsed with data being passed from your controller. Here's an example:

<script type="text/x-handlebars">
        <h2><strong>{{firstName}} {{lastName}}</strong></h2>
    </script>
    

In this case, the {{firstName}} and {{lastName}} expressions will be parsed by Ember and replaced by actual data. In addition, Ember sets up observers so that as your data changes, your template is automatically updated and the updates reflected to the user of your app.

So far, I've shown you a very simple example, but the takeaway is that:

• Ember uses a special type attribute to define templates.
• Templates use standard markup along with delimited expressions, which are parsed on the client-side.
• These templates have the full feature set capabilities of Handlebars.
• Ember sets up observers to dynamically update your user interface data, as it changes.

This offers a lot of flexibility in how you structure your user interface. Let's continue looking at the features that are available.

Advanced Expressions

Remember that Ember leverages Handlebars, so you have access to its full breadth of expressions here. Conditional expressions are a must, in order to render almost anything useful; Handlebars offers quite a number of options.

Let’s say that I had a JSON dataset that looked like this:

"items": [{
        "title": "Tearable Cloth Simulation in JavaScript",
        "url": "http://codepen.io/stuffit/pen/KrAwx",
        "id": 5592679,
        "commentCount": 20,
        "points": 127,
        "postedAgo": "1 hour ago",
        "postedBy": "NathanKP"
    }, {
        "title": "Netflix now bigger than HBO",
        "url": "http://qz.com/77067/netflix-now-bigger-than-hbo/",
        "id": 5592403,
        "commentCount": 68,
        "points": 96,
        "postedAgo": "2 hours ago",
        "postedBy": "edouard1234567"
    }
    

If I wanted to ensure that the title data is available, I could add a conditional "if" statement by using the #if expression:

{{#if item.title}}
        <li>{{item.title}} - {{item.postedAgo}} by {{item.postedBy}}</li>
    {{/if}}
    

This checks to see if item.title is not undefined, and continues processing the subsequent expressions for the title, postedAgo and postedBy data expressions.

Since this dataset contains more than one "record", it's safe to assume that we'd probably want to loop over each element of item. That's where the {{#each}} expression comes into play. It allows you to enumerate over a list of objects. So, again, keeping in mind that templates are a combination of markup and Handlebars expressions, we can use the #each expression to loop through every item available within our Ember model object. Remember that the Ember model is derived from the controller, which is associated to the template, via Ember's naming conventions.

<ul>
        {{#each item in model}}
        {{#if item.title}}
            <li>{{item.title}} - {{item.postedAgo}} by {{item.postedBy}}</li>
        {{/if}}
        {{/each}}
    </ul>
    

This would render out something similar to:

<ul>
    <li>Tearable Cloth Simulation in JavaScript - 1 hour ago by NathanKP</li>
    <li>Netflix now bigger than HBO - 2 hours ago by edouard1234567</li>
    <li>Fast Database Emerges from MIT Class, GPUs and Student&#39;s Invention - 33 minutes ago by signa11</li>
    <li> Connecting an iPad retina LCD to a PC - 6 hours ago by noonespecial</li>
    </ul>
    

The distinct advantage is Ember's implicit specification of observer,s which will update your data upon an update.

If your conditional expression needs to be more complex, you'll want to create a computed property. This allows you to create a property based off of a method that can apply complex code conditions to your data. Let's say I wanted to solely wanted to display data that had the title "Tearable Cloth Simulation in JavaScript". There's a couple of things I need to setup:

• I need a computed property to scan each item and tell me if the title matches
• I need to create a controller that can be used by each item being enumerated over in the template
• I need to update the template so that it uses this controller for each item
  The first thing I need to do is create the new controller that will wrap each item being looped over and create the computed property within it:

App.TitleController = Ember.ObjectController.extend({
        titleMatch: function() {
          return this.get('title') === "Tearable Cloth Simulation in JavaScript";
        }.property()
    });
    

Looking at the code, we're subclassing Ember.ObjectController to create the controller. This is the controller that will wrap each item being looped over in our template. Next, we're creating a method, called titleMatch which uses the get() method to pull back the current title, compare it to the text I've defined, and return a boolean. Lastly, the Ember property() method is called to define the titleMatch method as a computed property.

Once we have this in place, we update the template's {{#each}} expression to represent each item with the new controller we created. This is done by using the itemController directive. A key thing to understand is that itemController is a key phrase in Ember meant to associate a controller to items of a template. Don't confuse it for an actual controller name (as I did initially). The controller name is assigned to itemController, like this:

<ul>
       {{#each item in model itemController="title"}}
          {{#if titleMatch}}
            <li>{{foo.title}} - {{foo.postedAgo}} by {{foo.postedBy}}</li>
          {{/if}}
        {{/each}}
    </ul>
    

Again, naming conventions dictate that, when assigning names in templates, we use lowercase. In this case, we're assigning TitleController to itemController.

Now, as each item is looped over, the computed property, titleMatch, is used to evaluate the title and display data if it matches.

Binding Data to Elements

Creating dynamic templates isn't just about spitting out text. There are times when the look and feel of the UI needs to be affected by data being processed. Displaying an image or building a link are great examples of this.

Binding data to an element requires using special Ember helpers that assist in defining an attribute's context, as well as ensuring that the attributes are updated properly when data changes. For element attributes, the {{bindAttr}} helper is used to fill in the values for an attribute. If we needed to dynamically specify the URL of an image, we'd use the following syntax:

<img {{bindAttr src="logoUrl"}} alt="Logo">
    

The same can be done for attributes that don't receive a value, such as disabled:

<input type="checkbox" {{bindAttr disabled="isAdministrator"}}>
    

In this case, isAdminstrator could be a computed property based off a method in the controller, or just a normal object property giving you a lot of flexibility in defining the conditions for disabling the checkbox. This flexibility carries over to defining class names as well. If I wanted to use a conditional statement to define if a class should be applied to my element, I could use the following code:

<div {{bindAttr class="isUrgent"}}>
      Warning!
    </div>
    

Depending on the boolean state, my markup would either be:

<div {{bindAttr class="is-urgent"}}>
      Warning!
    </div>
    

for a true condition, or:

<div>
      Warning!
    </div>
    

for a false condition. Note that, when I specified isUrgent for the class, Ember dasherized the name and rendered the class as is-urgent. If you'd prefer to specify your own class based on the results, you can use a conditional expression similar to a ternary statement:

<div {{bindAttr class="isUrgent:urgent:normal"}}>
    

This will return urgent or normal for the class, based on the conditional value of isUrgent.

Get to Know Templates

Templates will be the foundation of your user interface, so it's going to be important that you spend time reading the docs at both the Ember and Handlebars site to get a good feel for their overall power. Even if you don't use Ember, Handlebars is a great framework for you to use day-to-day, and worth the investment in learning how to use it.

Gabriel Manricks wrote a great tutorial on Handlebars here on Nettuts+ that you can use to get up to speed on the framework.

The following full-time positions have been posted within the past week to UMBCworks. Login to your account (via the link in the Jobs & Internships topic in myUMBC) and find details and application instructions as well as hundreds of other job postings!

9258006 - Account Manager - Outside Sales - S. W. Betz Company, Inc.
9257992 - Analyst - Metron Aviation, Inc.
9256367 - Jr. Software Developer - Skyline Technology Solutions
9257977 - Production Engineer - Telarix, Inc.

The following part-time positions have been posted within the past week to UMBCworks. Login to your account (via the link in the Jobs & Internships topic in myUMBC) and find details and application instructions as well as hundreds of other job postings!

9257959 - Data Assistant - George S. Ingalls, P.A.
9257925 - IT Technical Support - Linwood Children's Center
9257956 - Birthday Party Hostess - Thumbs Up Party Planning
9257953 - Mental Health Companion - Help in the Home, LLC

Being able to code is pretty cool. It really does feel like a superpower to be able to create something from next to nothing. While it is a great idea for everyone to learn to code, I think it is not just a good idea, but essential for entrepreneurs with a business background who want to start something in the tech space, to learn to code.

For ease of writing I’m going to refer to these people (business guys with no technology education or know-how) as “business types”. In contrast, techies or “tech types” are tech-entrepreneurs and programmers in general. There are two important scenarios I want to highlight, where the lack of technology education on the business types’ part can lead to serious friction.

Scenario 1

First off, we have the business type who sees the tech world ablaze with success and wants in. They ‘ideate’ (I’m not a big fan of this word if you can’t tell) constantly until they stumble upon their big idea. What do they do next? They find someone who can build this for them. If they can afford to hire a programmer and pay a decent price to get the product out that’s fine. But often, their goal is to bring the techie on as a co-founder. This is a very common story and one that isn’t well received.

This is a completely acceptable response. A lot of business types think “Oh I’ll just ask someone to build the product for me. I’ll give them equity and they’ll be so happy to be a part of this.” Building the product is more than half the work in the early stages and you’re pretty much asking a random person to do all this work for you for nothing. Time, especially a programmer’s time, is a lot of money. Sure there is equity involved, but that’s a great incentive for founders and co-founders who start things together and are passionate enough about the project to forgo current earnings for the promise of startup glory.

Instead, learn to code. If you are a business type not currently engaged in a startup, but want to, then immediately learn to code. There are plenty of resources out there, I am obviously going to promote Treehouse.

By learning how to program, even if it is at a very basic level, you are doing a few things:

• You’re giving yourself, depending on how much you learn, the ability to start building out this idea of yours immediately. You can start working on a very basic iteration and see how it works.
• You realize the scope of the project. By understanding what it takes to build a web app, or an iOS or Android app, you will realize how long it will take to build something like this, what sort of work is involved, and what are the technological limitations. Is your idea realistic?
• You appreciate the techie’s role in all this and by putting in some of the effort, hopefully, you’ll start to earn some respect too. If you work on the project as far as your knowledge takes you, and then try to bring someone else on board, that’s completely different than asking them to do all the work.

Scenario 2

The second scenario is when a business type is already involved in a tech company (or any company for that matter), but still doesn’t have much knowledge of what building a tech product means. The underlying problems are the same; they don’t understand the scope of the problem, the limitations, the timelines, and so on. This problem is more common within IT departments of non-tech companies. Marketing hands down something last minute and wants it done in a few days. “Can’t you just build it?”

If any of these business types learned how to code, even at the most basic level, it would eliminate all sorts of problems. You end up with better team communication, more respect for one another’s roles, and more realistic deadlines for product teams.

So while it’s a great idea for the entire world to be programming literate, I think that anyone in business who lies on the fringes of tech, whether they want to start a tech company, or whether they are work with techies at their day job, should be required to have some basic programming education.

For the record, I consider myself a business type and I am learning how to code.

The post Why “Business Types” Should Learn to Code appeared first on Treehouse Blog.