As a former robotics engineer, my love of code was high, but my actual knowledge of HTML/CSS/JavaScript/allThingsWeb was rather low. Fortunately, the good folks at Skookum saw my potential and gave me a shot at pursuing my new-found passion, web development!

There are six major components to the Skookum Internship Program:

1. Projects
   1. Internal
      • On this project, I didn’t have to answer to any clients; instead, I worked with Josh, our Creative Director, to build something AWESOME. (And learn some skills on my own.)
      • Sometimes these projects are academic in nature, but they’re all good opportunities to get some good learning in.
   2. Client-focused
      • These real, client-based projects, are what make Skookum tick. Clients want the best product they can get for their hard-earned money, and I got to help make them happen.
2. Location
   1. Working at Trade & Tryon in Uptown Charlotte is pretty sweet.
   2. With a real office, too.
      • I didn’t get stuck in a closet away from all the cool kids; I actually worked right alongside the rest of the Skookum team. I worked on the same teams looked at the same code and ate the same lunch as everyone else.
3. Compensation
   1. Skookum’s Internship program is a paid position—how often does that happen in other industries?
4. Hours
   1. Just like the big kids, I got to work normal hours. In the web dev world, that’s not necessarily 9-5, which is awesome. But it’s full-time, not part-time, which means 40 hours/week of intense learning.
5. Mentors
   1. Every member of the Skookum team was accessible to me. I think the original point of the mentors was to have one mentor per intern, but I’m pretty non-traditional and I made everyone my mentor. For me, asking everyone for help was a good way to get to know the team and learn as much as I possibly could. Skookumites come in a wide variety of flavors: we’ve got Ruby pros, sick PHP devs, Node.js champions, and jQuery gurus, to name a few. To not take advantage of the diversity would be a huge mistake.
6. End-game
   1. The goal of the program is to transition interns into full-on (junior) developers. In some ways, it’s like the longest interview ever. But it’s also an amazing opportunity to get into the web development game, with a pretty low amount of risk for everyone.
   2. I’ll be honest—I wasn’t entirely sure that web development would be the right career for me when I started; it turns out I’ve been a closet web developer my whole life! The Skookum Internship program helped me find that out.
   3. It’s with that notion that I’m thrilled and honored now to be Skookum’s latest Junior Developer, hot off the presses.

All said and done, being an intern was crazy fun—I got to work with some really smart folks in hands-down the most relaxed and productive environment I’ve ever known. I’m shipping real code and making a real contribution to the team. Huzzah!

Now, if you’ll excuse me, I’ve got to get back to building a better Internet.

There are some really awesome authentication tools built right into WordPress that you can use verify a username and password within your WordPress install. You can even look at that user’s specific capabilities to determine if they get access or not based on their role or capabilities.

In the following example, I use PHP’s ability to present the user with a basic HTTP authentication dialog box, and then it’s authenticated against the WordPress database.

Only thing I haven’t done is set a cookie that keeps them logged in across browser sessions.

This works great if you’ve got an application that has a rewrite to a single index.php file to serve everything, or else put it into a header file that gets served on every page (above any HTML output since it sends our HTTP headers).

And remember: this security is only as good as WordPress security–which is to say “not very secure” but it sure beats an internal non-password protected server that anyone could access simply by plugging into your physical network and browsing around.

Rich’s cool talk covers internal vs. external design consistency, the Clear and Path iOS UI, Android designer woes, and a guy named Oscar (the Grouch).

Check out the Skookum Digital Works Tech Talk on Consistency in Interactive Design.

There’s been a drastic increase in the number of developer productivity tools as of late; particularly for frontend developers. These tools come in many shapes or forms, whether they be software, a command line interface, a domain-specific language (DSL), framework, database, etc. Below, I’ve created an abridged list of some of the top tools (my picks, I can’t speak on behalf of everyone). It’s quite lengthy, so each section is itself a collapsible accordion.

Popular Development Tools for Polyglots

Hint: Click on a particular topic heading to expand/view it’s children.

To Increase Productivity, Pick Your Niche

Given the plethora of tools listed above, I would personally recommend that you try to focus your attention on a small subset of competencies. The concept of a jack-of-all-trades-developer is diminishing. Our core skills are forking into distinct roles and disciplines. Companies are now looking for cutting edge frontend developers, backend developers, developers of operations, mobile developers, testing leads, and the list goes on and on…

If you’re looking to increase your productivity, you’ll likely benefit from becoming a specialist in a few areas above as opposed to a generalist in all. This doesn’t mean that you shouldn’t be reading up no new technologies and testing the waters. You should instead focus your attention on the tools that will help get the job done efficiently; knowing the trade-offs of each.

Never Stop Learning

Our industry grows at a pace inconceivable in other industries. To be honest, I’m pretty sure that’s why most of us are in the field to begin with. We love learning. If you believe that learning a new tool is going to benefit you in the long run and increase productivity, take the short-term hit and go do some research and development. You’ll be glad you did later.

For all you tech types out there that take pride in not knowing anything about sports, this is potentially a pretty big deal. ESPN is the ‘worldwide leader in sports’ and has a vast store of information, both current and historical, about all major sports (even hockey).

Six APIs have been released: the Headlines API, Research Notes API, Athletes API, Scores & Schedules API, Standings API and Teams API. Headlines and Research Notes are official releases, while the other four APIs are still in Beta. ESPN has divided the availability of the APIs into 4 tiers: public, partner, premium partner and ESPN.

The only API available to the public is the Headlines API (more on this later).

Using the API is pretty straightforward. A user signs up for a key and then uses that key to retrieve information in either an xml or json response. Error handling is built in, and a few examples are provided to guide the developer along. There is a limit of 2,500 calls per day and 1 call per second at the public tier. Apps must be branded appropriately as using the ESPN APIs.

Popular mobile/tablet apps like Pulse and Flipboard were given early access to the APIs and are featured in the Showcase section of the site to highlight how the Headlines API is already being used.

As an equal parts sports and technology fan, I’m excited about the potential of having access to one of the many things that ESPN does well – information about sports.

I am, however, a little disappointed with this initial offering. Though six APIs have been released, only one is available to the public, and it is by far the least sexy of the offerings.

Further, it is not clear on the procedure to become a partner or premium partner, save emailing an API opportunities address to get more information. According to the overview page, only ‘an ESPN moderator can upgrade your access to a different group.’ I’d like to see a clear description of what a relationship with ESPN would look like to an app or developer in the long term at each of the different tiers.

The terms and conditions state that the API, at least at the public tier, can only be used in apps that are non-commercial and do not feature in-app purchases. While I agree that any app that would blatantly rip off the information that ESPN provides and be for sale is deplorable, what about apps that may use any of the APIs as supplemental information in an existing sports-related app? If that app charges a fee for use, it can’t utilize any of the ESPN APIs as a value-add to its already existing offering.

Also, 2,500 calls per day is fairly low. Sure, calls can be cached, and sports does not happen that fast, but Google Maps caps their daily API calls at tens times the amount that ESPN offers. To me, that’s a significant difference.

Despite misgivings on the initial rollout of the APIs, I think the potential of the ESPN Developer Center is too great to not take advantage of in some capacity. Overall this new endeavor from ESPN will probably prove to be successful.

Tell us what you think. Are the ESPN Developer APIs exciting, or do you think they’re kinda lame at this stage? How big is the developer/sports fan Venn diagram overlap?

A Browser without the Browser.

PhantomJS describes itself as a “headless WebKit with JavaScript API”. For those that are not familiar, WebKit is the open-source web browsing engine that powers popular browsers including Chrome and Safari. “Headless” refers to fact that the program can be run from the command line without a window system, making it perfect for the server environment. The JavaScript API means that we can easily write scripts that interact with PhantomJS in the language of the web, allowing us to modify the browser output on the fly, just like you can do with Firebug or Developer Tools locally!

Installation

The hardest part of working with PhantomJS is getting it installed. Because of the requirements you are not going to be able to run this on a standard shared host, but an average vps will handle it fine. The following instructions are for getting things up and running with Ubuntu 11.10 on Linode.

Step1: Install PhantomJS Requirements

This will install everything we need to compile PhantomJS, along with the ability to run it virtually without a window system.

Step2: Install Browser Goodies

Installs flash plugin and windows fonts so sites appear more accurate.

Step3: Compile!

Clone the repo and build from source.
After everything finishes we should now have the program installed. Test it at the command-line by typing “phantomjs”

Taking Screenshots

Since PhantomJS scripts are simply javascript with some extra api calls baked in, the barrier to entry for web developers is zero! Create the following script and save it somewhere on your server as “shotty.js”. Check out the comments for an explanation of what is happening.
To run this script, navigate to where the script lives on your server and run the following command. We run “Xvfb -screen 0 1024x768x24&”  first to set the parameters of our Xvfb screen buffer. This is basically a virtual screen that allows us to emulate a window environment. Then we call the script with “DISPLAY=:0 phantomjs –load-plugins=yes shotty.js” to ensure Phantom runs in the buffer. PhantomJS will execute our script and save our screenshot in the same folder the script is in. If everything went well our screenshot of espn.com should look just like the real thing. How cool is that?

Muck’n with Markup

Because PhantomJS scripts are JavaScript, that means we can easily perform actions on the result of a page, and then take a screenshot of the results! Below we have created a script that grabs a page, embeds jQuery, and then performs some DOM manipulation before finally taking a screenshot. Priceless. The following code will allow us to edit the headline on espn.com to say whatever we want.

I’m sure by now your gears are already turning on fun uses of this technology. In Part II of this series I will go over how to integrate with Node.js to create a Phantom powered web app.

At the beginning of the world, people had no fire. The only fire anywhere was on top of a high mountain, guarded by the Skookums. You see, these Skookums were not like the fine and friendly Skookums we have today, these Skookums were total hoarders. They didn’t want the people to have fire, because if they did, then maybe they would become as powerful as the Skookums.

A coyote thought he’d be sly and go steal a brand of fire and bring it to the people. After consulting his three sisters for advice, (in an odd twist of events, the three sisters lived in the coyote’s stomach in the form of huckleberries…but I digress), the coyote lined up all the animals in strategic places along the mountainside in a line between the Skookum’s fire and the people.

The coyote stole some fire while the Skookum’s were chillaxing, then the animals basically relayed raced the fire until eventually an antelope gave the fire to a frog, who swallowed it. The frog then spat out the fire onto a piece of wood. The Skookum’s—kinda mad at this point—couldn’t figure out how undo the frog-fire-wood-spit, so they went back to the top of the mountain, presumably to resume chillaxing. The coyote then showed the people how to get the fire out of the wood by rubbing sticks together—and that’s why you can eat and be warm now.

So, why did I tell you this story? Because today’s Skookums aren’t hoarders. We don’t want to withhold our technology expertise, our “fire” if you will, from the people.

We don’t want coyotes up in our business either. So trust me, we’ll give you the fire. Just ask. Or come to a Friday Tech Talk.

*Illustrations by Rich!

Jason started working at Skookum about five months ago. Before that, he worked at a company that installed and seviced ShoreTel VoIP phone systems.

We asked Jason to introduce himself and talk about what he’s learned coming from a non-programming (though still technical) career into software development. Take it away, Jason.

At my last job, along with installing the phone systems, diagnostics and upgrades to the current network were almost always needed to get the needed voice quality. The company was just five people including the owner. The relationships formed within a small team like that are awesome. So why move to NC and take a new job then? The weather! I lived in north central Ohio…and like a lot of other NC transplants, I’d have a hard time going back to grey skies and bad winters.

But from a technical angle, I also was excited about the challenge of doing and learning something new. I’ve had a desire to improve my knowledge and toolset for some time. Coming to Skookum Digital Works, I really didn’t know what I would be doing, but it was clear they thought I had the capacity to grow if surrounded with the right teammates.

SDW does software development. I had some experience…mostly with ASP Classic (no laughing). No PHP. No node, No JavaScript, No CSS. No HTML5. Basically, no experience. Would I measure up? Would I really pick up those languages with the right guides?

Well here I am, five months in. I have not done any ASP Classic programming, but that’s (more than) OK. What I have done is learned a whole lot. I’ve picked up more programming skills in the last five months than I had in the rest of my previous jobs combined. I have used PHP, JavaScript and jQuery, node, knockout, CSS, and HTML5. I’ve also picked up some design and layout tricks, and I’ve even learned how to stretch and use WordPress as way-more-than a simple CMS.

And, do I like it here? Well, the work environment has a very similar feel to the small company I was at before. Everyone at SDW is awesome, smart, and willing to help when asked. Everyone here likes to operate out of their comfort zone and continue learning new things. And when someone makes a breakthrough, there’s usually a tech talk to coincide.

Looking toward the future, I hope to learn as much about new technologies and languages as I can. I want to learn more node, and wouldn’t mind learning Ruby at some point. I also would like to build an iPhone, iPad, or Mac app. There are things I need to be better at, and I am trying hard. My CSS, javascript, and code testing all need improving. I am learning as fast as I possibly can and look forward to learning even more. And as I move forward, a goal of mine is to help keep people informed of the new awesomeness that I find, because we all know, we will never know it all.

I’m not going to do a dissertation on the nuances of using cURL. Instead, I’d like to discuss how to process data after you’ve gotten the HTML string from a page using the curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1); setting. The general process using cURL to get the data from a password protected site goes something like this:

1. Make sure your “cookie jar” is set up and working so that your session can be saved while you’re scraping other pages after login.
2. Get the HTML for the login page.
1. Get the form post location.
2. Get any special tokens or hidden variables.
3. Post to the login script with your authorized username and password.
4. Scrape any pages you need to get and process them.

Getting auth tokens and stuff

Sometimes login pages make it difficult to figure out what to post because of “authentication tokens” or similar variables that change every time a page is hit and then have to be posted back along with the username and password. This is most common among .NET applications since it’s built right in to the .NET form creation classes. The process of finding these variables is made a lot easier if you use phpQuery. It’s a project that attempts to replicate what jQuery does but with PHP. You pass phpQuery a string with all the HTML content in it and then you can perform selectors and traverse the DOM just like with jQuery. What you do with the HTML after that is up to you.

In the above example, I already had the HTML string of the login page and simply used phpQuery to get all the inputs on the page with a very jQuery-like selector syntax and then looped through the results to get all my input fields for the form so I could use them in my next call to post the data back to the login script.

Getting poorly formatted data and stuff

I consider “well formatted” data to be in formats like JSON, XML, CSV, etc. that are specifically meant for data transfer. But what heppens when you need to scrape data from HTML tables or DIVs?

phpQuery to the rescue! You can do the same thing as above but parse the newly acquired HTML string of the data you’re looking for. Here’s an example of looking at a two column table of data to get all sorts of neat stuff and format it into an array. Then I check for an element outside of the table loop and set another variable.

Using the data and stuff

After you’re done with that, you have all this useful data in an array and you can basically do whatever you want to it. Since this example I created originated from code used in a real life client project (with variable names changed to protect the innocent), I went on to take that array and save it out to a JSON file that I could easily read in and do what I wanted to with the data.

You may need to go through some tests to get the right kind of cleaning or data sanitization for your values, but phpQuery makes it really easy to scrape this kind of data if you’re used to jQuery’s selectors and traversing. Instead of scraping the site each time to get the data, I like saving out the html string to a file and then playing with selectors and traversing to get the data I want form a local file so I don’t put a lot of strain on the server.

And don’t forget stealth…

If you’re not sure how friendly the server (or serveradmin) is to you doing this, make sure you set the cURL user agent for each request. I like  pretending I’m GoogleBot, but any common user agent string would suffice so that the server doesn’t explicitly know you’re PHP trying to log in.

By default, cURL spits out a user agent like this (changes based on operating system and version of cURL):

curl/7.15.5 (i686-redhat-linux-gnu) libcurl/7.15.5 OpenSSL/0.9.8b zlib/1.2.3 libidn/0.6.5

If a serveradmin sees that in their logs, they might freak out… so  I like these user agent strings for sneaky data pulls:

Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)
Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_2) AppleWebKit/535.7 (KHTML, like Gecko) Chrome/16.0.912.77 Safari/535.7

Audience participation

How do you use cURL and phpQuery? Any useful scripts or resources to point people to other than their respective documentation sites?

Tell us a little about what Skookum Digital Works does and how it was founded?
Skookum Digital Works is a technical partner for anyone with a startup dream. We mainly work with entrepreneurs—building out their products or customizing software for businesses. 

My co-founder and I, Bryan Delaney, founded Skookum in 2005. We were roommates at UNC Charlotte, both graduated with computer science degrees, and both went to work for the Department of Defense for a few years before deciding we had a better mousetrap. 

Bryan and I are Charlotte natives, and we’re happy to have located our office Uptown. 

Do you specialize in any particular types of apps or client base?
I don’t think its crass of me to say we like to work with funded startups. Our typical client is the non-technical entrepreneur; someone with business skills and ideas but with no programming background. We allow a non-technical entrepreneur to get started on their digital product without having to find a technical co-founder or trying to hire engineers they are not qualified to vet. 

Our clients have often heard the word “No” elsewhere. We have expertise in the mobile web, complicated software integrations, and real-time web collaboration. 

What are some examples of apps Skookum has created?
A publishing company wanted a marketing tool to promote their books. SDW gave them a digital revenue stream.

Some D.C. folks knew independent voters were eager to take collective action. SDW built them a data mining and people matching system.

A group of investors-and-avid-golfers hated the 100+ scoring apps already available. We made players’ phones talk to each other. (!)

A neighborhood of New York businesses disliked Groupon keeping their margins. We created a localized model they collectively controlled. 

What do you think will be the next innovation in smartphone applications?
Mobile apps are going to be easier to download and live outside the walls of the Apple iTunes store and the Android Marketplace. Companies can now place their applications on iPhones and iPads without Apple taking 30% of the cut. 

Mobile applications are also slowing making their way into retail. Most stores know they can use smartphones and tablet devices to enhance their store experience, but the smaller chains (and certainly the local guys) are waiting to see what the big guys do before making the investment. 

Charlotte isn’t really seen as a tech town. Will that ever change?
It’s fundamentally a marketing problem and one that we and 70+ other Charlotte tech leaders have addressed face to face with Mayor Foxx. Aside from numerous local startups and technical partners like ourselves, all of the banks are essentially technology companies. 

For just one example, If you took all the programmers out of Bank of America, they would comprise the tenth largest tech company in the world. BoA has technology needs that make engineers at IBM cry. 

We like to think we’re doing our part recruiting talent to the area and flying the flag in front of national entrepreneurs. We have clients all over the place happy to come see us and come visit Charlotte. 

Charlotte is already a tech hub, but the city definitely needs to get better about spreading that message.