If you’re a designer or developer with an idea for a new product or website, the chances are that you will need someone who has the skills that you lack in order to help make it a reality. It’s a problem that we all recognise but one that some appear to have more trouble solving than others.

On numerous occasions I’ve seen app concepts posted to Dribbble that have been highly praised by commenters but unfortunately will seemingly never materilize. Why? Well the designer’s excuse is usually that they don’t know anybody that would help to build it.

With developers, it’s often the case that they don’t know anybody that would help to design it.

If you’re guilty of making such excuses then you’ll know that this isn’t entirely true. There’s plenty of designers and developers out there that you could hire to do the job. The real problem is not having the funds to do so, which means having to find someone who’s willing to do these things for free.

Well, not quite.

Anybody who’s going to put work into a project is going to want to be paid something for their efforts. This is why, if you’re not able to pay someone a set fee, you’re going to need to find someone who believes in what you’re trying to do, isn’t afraid to take a risk and is willing to invest their time in return for a share of the profits.

What you need to find is a partner.

Preparing for your search

In a lot of ways finding a partner is similar to finding an investor, except rather than investing their money they’ll be investing their time and it’s up to you to sell them your idea and convince them that it’s going to be worth doing so. 

It’s not going to be as simple as sending someone an e-mail and just saying “Hey, I’ve got this idea for an app. It’s going to be like OpenTable but for bars. I was wondering if you wanted to partner up and help me bring it to life?”.

If you find someone that’s interested it’s likely that there’s going to be a lot of back and forth as no doubt they’ll have a number of questions. Even after exchanging a handful of e-mails and phone calls they might decide that it’s just not for them. As a result, you may have to repeat the process several times before finding a willing candidate.

Where to look

Once you’re ready to get your search underway, a good place to start is by asking friends for recommendations as they can put you in touch with people that they may have worked with in the past. This is helpful because that way you know that at least they can be relied upon and your friend can assure them that you’re a trustworthy character.

Next up is Twitter. Simply send out a couple of tweets explaining that you’re looking for someone with a particular set of skills to help with your latest project and that you would appreciate if those with said skills were to get in touch. You should also ask your followers if they have any recommendations.

Following that, check out some of the websites designed especially for connecting designers and developers. Two popular examples are Builditwith.me and Programmer Meet Designer, both of which are free and easy to use. All you have to do is sign up and post a couple of details about your project along with a list of the skills required to help finish the job. You could also try a promising new tool called the Assemblr.cc newsletter which aims to pair up designers and developers via a weekly newsletter. Simply submit your name, contact details and a 140 character description of your project and have it sent directly to a list of designers and developers eager to work on new projects.

Finally, you can also take a more direct approach by searching for people with the required skills on websites such as Linkedin, Zerply, Dribbble, or via a good old fashioned Google search. Once you’ve found a suitable candidate, contact them directly, explain your situation and ask them if they would be interested in discussing it in further detail. If they live in the local area you could even arrange to meet up and talk about it over a coffee (on you of course).

Just remember

Once you’ve finally found someone willing to team up, remember that you’ve agreed on forming a partnership and that they are not working for you but with you. Just because the idea was yours doesn’t mean that everything has to be your way. It should be a collaborative process and you should remain open to the other person’s ideas. If you don’t then you could very quickly find yourself back at square one.

On the other hand, if all goes well, it could be the beginning of what proves to be a long and prosperous business relationship.

So, to conclude, if you do have an idea for a new product or website, don’t let lack of skill or money hold you back. Bootstrap your ideas into actual products – team up, build and ship.

Have you teamed up to develop a product? Are you currently searching for partners to work on a project? Let us know in the comments.

Featured image by Michael Himbeault.

The Only Journal App You Will Ever Need for Windows or Mac – only $19!

In this episode of The Treehouse Show, Nick Pettit (@nickrp) and Jason Seifer (@jseifer) talk about SVG and Icon Fonts, Typography and CSS Sliders.

Here are the links for the week:

Brackets
http://brackets.io/

hull, Reconciling SVG and Icon Fonts
http://blog.hull.io/post/47939445232/reconciling-svg-and-icon-fonts

Ui Parade – Live Tools
http://livetools.uiparade.com/index.html

Avoiding Unnecessary Paints – HTML5 Rocks
http://www.html5rocks.com/en/tutorials/speed/unnecessary-paints/

Typeplate » A typographic starter kit encouraging great type on the Web
http://typeplate.com/

JavaScript Regular Expression Enlightenment – Tech.Pro
http://tech.pro/tutorial/1214/javascript-regular-expression-enlightenment

Slider with Sliding Backgrounds | CSS-Tricks
http://css-tricks.com/slider-with-sliding-backgrounds/

ClippyJS – Add Clippy or his friends to any website for instant nostalgia
http://www.smore.com/clippy-js

The post SVG and Icon Fonts, Typography and CSS Sliders – Treehouse Show Ep 43 appeared first on Treehouse Blog.

Greg Cangialosi ’96 (far right) talks with students about careers in the startup industry at the Betamore Startup Crawl, which he hosted in May.

As a master of marketing tech and entrepreneurship, UMBC alumnus Greg Cangialosi ’96, English, always seems to be two – or ten – steps ahead of pretty much everyone else. He has to be.

When many of us were still figuring out listservs, his vision for power e-marketing was already permanently changing the communications scene. When we finally started to grasp the concept of “the cloud,” he had already measured potential and created a community for big thinkers and even bigger collaboration. Follow him on Twitter, and it sometimes feels like time travel.

And yet, in the best of ways, Cangialosi is an old-fashioned guy with a timeless sense of what really matters. A generous volunteer, he embraces the three pillars of philanthropy – time, talent and treasure – and UMBC is all the better for it.

Last month month, Cangialosi made a five-year commitment to UMBC totaling $100,000 to support the creation of a business innovation competition and an endowment that will support student entrepreneurship initiatives, including everything from new courses, guest speakers and potential seed money for budding student start-ups.

“I have had wonderful experiences in all three realms of giving back and I think they are all important as they all make an impact,” said Cangialosi, who sold his start-up email marketing firm Blue Sky Factory in 2011 and recently co-founded Betamore, an 8,000 square foot “urban campus for entrepreneurship and technology, focused on three main areas, education, community and incubation” in Federal Hill.

“My recent experience, teaching, has given me the closest connection to the students, student life, and how many amazing things are happening on campus and around the university,” he said. “UMBC is moving forward, making things happen, and it’s great to be part of that momentum.”

Since his graduation in 1996, Cangialosi has played many roles as an alumnus and donor. He has judged UMBC’s annual Idea Competition, and served as a speaker for the Alex.Brown Center for Entreprenership and Career Week. A former member of the Alumni Association’s Board of Directors, he was named an Outstanding Alumnus of the Year in the Humanities in 2012. And last year, he taught “Entrepreneurial Marketing” at UMBC for the first time – an experience he found “challenging yet rewarding.”

“Greg’s relationship with campus has so many dimensions,” said Greg Simmons ’04, Vice President of Institutional Advancement.

“From his early days an entrepreneur – when he let us use his e-mail marketing platform to publicize university events like the IT Visionaries programs – to his work on the alumni board, he has always demonstrated great commitment and energy to finding ways to be supportive of UMBC.  Seeing him enjoy teaching has been great.  And this recent demonstration of his commitment – via philanthropy – shows a great alignment of UMBC’s efforts and his own value system.”

Cangialosi’s gift will further solidify UMBC’s entrepreneurship program, said Vivian Armor ’73, director of UMBC’s Alex.Brown Center for Entrepreneurship. She expects the Cangialosi Business Innovation Competition to become a major source of support and inspiration for students looking to become successful entrepreneuers.

“We’ll be able to create a very immersive experience for students,” including potential cash prizes for winning ideas, as well as structured mentorship opportunities, she said.

Through his teaching and connections to UMBC, Cangialosi has been able to further provide opportunities for students. Recently, Betamore hosted a “Startup Crawl” for more than 80 students from around Baltimore (including a couple dozen from UMBC) as a way of “getting students exposed to the startup scene here in Baltimore, and at the same time exposing new emerging companies to the amazing talent pool here in Baltimore,” Cangialosi said.

Twenty companies participated, all of whom were hiring either full time positions or internships. Students mixed and mingled, getting a taste for employment options they might not otherwise have considered.

“What I got out of it was great networking,” said newly-minted alumna Monica Berron ’13. “I had no idea we had a burgeoning entrepreneur community in Baltimore. I met a great group of women, for example, who have business called Drio who create website for bloggers and businesswomen, which is something I’m really interested in.”

“Aside from networking and meeting a lot of the founders, a portion of the Startup Crawl also included a session in which each company presented to all the attendees,” said senior Andrew Mavronicolas, who recently took Cangialosi’s class, and who is majoring in information systems with a minor in entrepreneurship. “From this, we not only learned about their companies, but some of the struggles they went through along the way.

Always looking ahead, Cangialosi is already hoping to host another Startup Crawl for the fall. And UMBC students will definitely be a part of it.

“I love UMBC first and foremost,” he said. “I am also a big believer in giving back and helping to make the places and the institutions that support you better and better. That happens by giving back.”

Learn more about entrepreneurship at UMBC here.

The following is a guest post by Parker Bennett where he explores some different ways to approach the behavior of fluid and responsive images.

Sometimes you want an image to resize responsively but restrict its height — cropping it then as it widens. Here, we explore three options with various trade-offs.

Option One: background-image

Edit on CodePen

Here, in place of an <img>, we create a div with a background-image and use CSS3's dandy new background-size: cover to have it size proportionally. As a bonus, we can easily crop from the top, center, or bottom using background-position.

One potential issue is we need to specify a height for the div to show up. This gives it a fixed height that doesn't scale proportionally (at least not without CSS media queries). When it gets narrow enough, the sides start cropping (this might be preferable, it depends).

Also, a quick check with caniuse.com shows this will fail conspicuously in IE8 (showing the image full size), but thanks to Louis-Rémi Babé, there's a background-size polyfill workaround (though it does require a relative or fixed position, and a z-index). IE8 also needs a polyfill for CSS media queries. There are a couple options.

.bg-image {
      /* image specified in separate class below */
      height: 240px;
      width: 100%; 
    }
    
    .bg-image-wedding {
      background-image: url(img/photo-wedding_1200x800.jpg);
    
      /* lt ie8 */
      -ms-background-position-x: center;
      -ms-background-position-y: bottom;
      background-position: center bottom;
    
      /* scale bg image proportionately */
      background-size: cover;
        
      /* ie8 workaround - http://louisremi.github.io/background-size-polyfill/ */
      -ms-behavior: url(/backgroundsize.min.htc);
      /* prevent scaling past src width (or not) */
      /* max-width: 1200px; */
    }
    
    /* example media queries */
    @media only screen and (min-width : 768px) {
      .bg-image { height: 320px; }
    }
    
    @media only screen and (min-width : 1200px) {
      .bg-image { height: 400px; }
    }

Something to note, background-size: cover will readily upscale larger than the src image's native size (or not, if you set a max-width).*

Still, there are some downsides to using a background-image. It's not as semantic or modular as an img, so it's less straightforward to maintain. You're seemingly stuck with a fixed height or cumbersome CSS media queries. Also, users can't save the image as easily (sometimes preferable).

Option Two: img with a Twist

Edit on CodePen

Here, we use an img with max-width set to a percentage of the containing element so it scales responsively, then wrap it in a div with overflow: hidden and a specified height or max-height.

.crop-height {
      /* max-width: 1200px; /* img src width (if known) */
      max-height: 320px;
      overflow: hidden; 
    }
    
    img.scale {
      /* corrects inline gap in enclosing div */
      display: block;
      max-width: 100%;
      /* just in case, to force correct aspect ratio */
      height: auto !important;
      width: auto\9; /* ie8+9 */
      /* lt ie8 */
      -ms-interpolation-mode: bicubic; 
    }

As you can see, the bottom of the image now gets cropped as it widens. But what if you want it to crop from the top? Surprisingly, you can — using CSS3's transform:rotate() we add a "flip" class to both img.scale and div.crop-height — flipping the img all the way around.

/* apply to both img.scale and div.crop-height */
    .flip {
      -webkit-transform: rotate(180deg);
      -moz-transform:    rotate(180deg);
      -ms-transform:     rotate(180deg);
      -o-transform:      rotate(180deg);
      transform:         rotate(180deg);
      /* needed? not sure */
      zoom: 1;
    }
    
    img.flip {
      /* if native or declared width of img.scale
         is less than div.crop-height, this will
         flipped img left */
      float: right;
      /* add clearfix if needed */ 
    }

Novel, but limited to top-cropping only. And, as you might expect, this doesn't work in IE8, either — perhaps failing less conspicuously (it will just crop from the bottom as before). The bad news is, I haven't found any polyfill options that work because they need a specified height and width.

Option Three: Hybrid Approach

Edit on CodePen

What if we could have the advantages of specifying an img (e.g., using max-height so we get proportional vertical scaling below a certain height), but also the flexible cropping and IE8 polyfill support afforded a background-image? We can!

The trick is to make the responsively-sizing img invisible. With visibility: hidden it retains layout, so we see the background-image behind it. (Since it's the same image source it shouldn't have to download twice.) If you want user-friendly access, you could instead use opacity: 0. Now users can drag the image or right-click to save. (Opacity and background-size need some extra IE8 workaround bits.)

Another thought is to use a more compressed proxy img, and use CSS media queries to serve a higher-resolution background-image as needed. This img could even be a proportionately smaller size (e.g., matching your max-height), or watermarked. Check out this CSS-Tricks post on media queries, and this helpful resolution mixin for Sass.

.crop-height {
        /* max-width: 1200px; /* img src width (if known) */
        max-height: 320px;
        overflow: hidden; }
    
    .bg-image-wedding {
        /* for small devices */
        background-image: url(img/photo-wedding_1200x800.jpg);
        /* lt ie8 */
        -ms-background-position-x: center;
        -ms-background-position-y: bottom;
        background-position: center bottom;
        /* scale bg image proportionately */
        background-size: cover;
        /* ie8 workaround - http://louisremi.github.io/background-size-polyfill/ */
        -ms-behavior: url(/backgroundsize.min.htc);
        */ prevent scaling past src width (or not) */
        /* max-width: 1200px; */ }
    
    .invisible {
        visibility: hidden; }
    
    .transparent {
        /* trigger hasLayout for IE filters below */
        zoom: 1;
        /* 0 opacity in filters still displays layout */
        -ms-filter:"progid:DXImageTransform.Microsoft.Alpha(Opacity=0)";
        filter: alpha(opacity=10);
        opacity: 0; }
    
    /* example media query for smaller non-retina devices */
    @media
        only screen and (max-device-width : 600px) and (-webkit-max-device-pixel-ratio: 1),
        only screen and (max-device-width : 600px) and (        max-device-pixel-ratio: 1) {
          
         .bg-image-wedding {
           background-image: url(img/photo-wedding_600x400.jpg); 
         }
    }
    
    /* example media query for retina ipad and up */
    @media
        only screen and (min-device-width : 768px) and (-webkit-min-device-pixel-ratio: 1.5),
        only screen and (min-device-width : 768px) and (        min-device-pixel-ratio: 1.5) {
    
          .bg-image-wedding {
            background-image: url(img/photo-wedding_1200x800@1.5x.jpg); 
          }
    }

Wrapping Up

Until the day where CSS3's object-fit is supported, which may be a while, this hybrid option seems like the best approach to me. Still, it's nice to have options. I hope you got something out of my way-too-thorough exploration. You can take a look at the source code for more, edit on CodePen, or download the example files here. If you have any questions, comments, or corrections, drop me a line: parker@parkerbennett.com.

* You can make an img upscale like a background-image if you want. You just need to "pre-enlarge" it, adding a proportionately larger width and height to the img element itself: <img width="2400px" height="1600px" src="img/photo-wedding_1200x800.jpg /> (edit on CodePen).

Crop Top is a post from CSS-Tricks

Update (13.06.2013): The SmashingConf 2013 is sold out just 48h after the ticket sales launch. However, some workshop tickets are still available. We can’t wait to welcome you, dear attendees, in September in Freiburg! In fact, we’ve got quite a few surprises waiting for you; please stay tuned. You won’t be disappointed.

Guess what? The Smashing Conference is coming! 2 single-track conference days, 3 full-day workshops, 16 excellent speakers, and only 300 available seats. We’d be honoured to welcome you in our home town Freiburg, on September 9–11th 2013, at the foot of the legendary, beautiful Black Forest in Southern Germany.

You can enjoy the well-known “Münsterwurst” opposite the conference venue, also known as a “lange Rote”. Of course, there are also vegetarian tofu sausages available. Image credit.

SmashingConf 2013: We Are Building The Web

We want the Smashing Conference to be a unique, valuable and friendly event for everybody involved. Not only do we want to provide new perspectives into Web design in general; more importantly, we want the event to focus on how exactly we, designers and developers, work, design and code to solve real-life problems.

Tickets can now be purchased via the SmashingConf 2013 page.

We’ll explore in detail what techniques, strategies and tools we use, but also what lessons we can learn from our personal experiences, successes and failures. Smashing Conference is a conference about how we work and play — and how we build the Web today.

Get your ticket!

Speakers and Workshops

We’ve invited excellent speakers who all have something to share, be it personal experiences or case-studies on large projects. We’re very happy to welcome Jason Santa Maria, Dan Mall, Luke Wroblewski, Dan Rubin, Inayaili de Leon, David Březina, Andy Hume, Tim Kadlec and — of course — the Mystery Speaker among the first confirmed speakers. You can find more information about the talks on the SmashingConf 2013 Speakers page.

Taking notes the old-fashioned way. Image credit.

We are also happy to announce 3 full-day and 1 half-day practical, hands-on workshops that will take place after the two main conference days: Dan Mall will be teaching how to be the typographer you were born to be, Dan Rubin will be exploring how to design for User Experience, Luke Wroblewski will be exploring how we can improve Web forms for mobile, and Addy Osmani will be teaching how to become the real front-end warrior.

Does it all sounds good to you? Well, it gets even better: If you purchase a Conference Ticket + Workshop ticket, you can save 15% off the regular price! So what are you waiting for?

Date, Location, Prices

The conference will take place on 9–11th of September in 2013 in the Historic Merchant Hall in our lovely home town Freiburg, Germany. We have only 300 seats, so the number of tickets is very limited. Also, we’ve blocked every single hotel in town for you — you can select your hotel at the SmashingConf 2013 Location page (“Smashing Conference” is the magic word for hotel booking!).

Image credit.

AirBnB could be a good option as well, but be fast — there aren’t many rooms available. Freiburg is known for being a vacation place, so perhaps you’d like to combine the conference with a relaxing family vacation in the skirts of the Black Forest? We’ve prepared some information about the location of Freiburg, so you don’t get lost in the suburbs of the Southern Germany while travelling here. Now if that isn’t an experience of a life-time, what is? (No, seriously, you will enjoy it!).

The price per ticket is €369 (incl. VAT). We’re organzing 3 full-day (€349) and 1 half-day (€229) workshops. Make sure to actually consider booking a workshop as well — if you buy both a conf ticket and a workshop, you save 15% off the price right away. Three days of learning, sharing, networking — it’s getting better and better! No lunch will be provided, but drinks and snacks will be provided, of course.

Get your ticket!

Sponsors, Dear Sponsors

We keep the ticket prices affordable for everyone, and we’re happy to welcome sponsors to help us make the conference smashing in every possible way. If you’re interested in sponsoring the event, please contact Vitaly at hello [@] smashingconf [dot] com. We love our sponsors, and you make the event possible, and we’d be honoured to have you involved!

Snapshot of SmashingMag’s 2012 Conference badge and lanyard. Image credit.

• “This conference was well worth the money and I hope we will make it next year. Well done Smashing Magazine!” (Source)
• “The two days of talks offered a very good balance of design-, philosophy-, typography-, and development-based topics. [...] Thanks to all who attended, organized, cared, spoke and made this an overall very great event!” (Source)
• “It was an immensely successful conference [...] The talks, the beer and the interesting people definitely made me want to go visit Freiburg again next year!” (Source)

Questions?

Follow us at @smashingconf and get more details on the SmashingConf 2013 website. Also, more speakers will be announced soon, so get ready to be smashed with a few exciting surprises and announcements!

Questions? Shoot us an email anytime at hello@smashingconf.com — we’d love to assist you in every possible way and would be humbled and happy to welcome you in our lovely home town Freiburg this September!

Auf Wiedersehen!

Get your ticket!

© Vitaly Friedman for Smashing Magazine, 2013.

When a team builds a complex application, there is often a common breakdown of roles. Specifically on the back end, there are database engineers, application engineers and operations engineers, or something close to this. In recent years, more and more application logic is being deferred to the client side. For some reason, though, operations folks aren’t going with it.

I recently wrote an article on “Deploying JavaScript Applications.” It was largely well received, and I was happy with the content, but one negative comment stuck out to me. I probably didn’t have the reaction that the commenter was intending, but it pointed out something to me nonetheless.

“With all due respect, may I ask if you actually enjoy your job? I am a dev, and I do enjoy using tech to do stuff to a point. If your role is to squeeze every last second of performance out of your app, then yea, all this stuff must be cool. BUT if you are a coder doing something else and then come back to all of this as well, then wow, I don’t know how you haven’t gone mad already. I’d be sick to the stomach if I had to do all of this, in addition to my usual work.”

See, I had written my article with a few too many assumptions. I understood ahead of time that a few of my solutions weren’t globally applicable, and that many people wouldn’t have the time or energy to implement them. What I didn’t fully grasp was how different the role in that article is from the picture that people have of a front-end developer in their head. Up to this point, a front-end developer had just the few operations duties lumped into their role, and even then, many people chose to skip those steps (that’s why Steve Souders is constantly yelling at you to make your pages faster).

I think things are about to shift, and I’d (humbly) like to help guide that shift, because I think it’ll be great for the Web.

The Front-End Operations Engineer

A front-end operations engineer is not a title you’ve likely come across, but hopefully one that you will. Such a person would need to be an expert at serving and hosting front-end resources. They’d need to be pros at Grunt (or something similar) and have strong opinions about modules. They would find the best ways to piece together the parts of a Web application, and they’d be pros at versioning, caching and deployment.

A front-end operations engineer would own external performance. They would be critical of new HTTP requests, and they would constantly be measuring file size and page-load time. They wouldn’t necessarily always worry about the number of times that a loop can run in a second — that’s still an application engineer’s job. They own everything past the functionality. They are the bridge between an application’s intent and an application’s reality.

A front-end operations engineer would be very friendly with the quality assurance team, and they would make sure that “performance” is a test that comes up green. They’d monitor client-side errors and get alerts when things go wrong. They’d make sure that migrations to new versions of the application go smoothly, and they’d keep all external and internal dependencies up to date, secure and stable. They are the gatekeepers of the application.

Why?

We have reached a point where there is enough work to be done in the operations space that it often no longer serves us to have an application engineer do both jobs. When the application’s features are someone’s priorities, and that person has a full plate, they will typically deprioritize the critical steps in delivering their application most successfully to the end users.

Not every company or team can afford this person, but even if someone puts on the “front-end operations” hat for one day a week and prioritizes their work accordingly, users win. It doesn’t matter how many features you have or how sexy your features are if they aren’t delivered to the user quickly, with ease, and then heavily monitored. Front-end operations engineers are the enablers of long-term progress.

Builds And Deployment

If you were to ask most back-end engineers which person on their team has traditionally worried about builds and deployment, I’m sure you’d get a mixed bag. However, a very sizeable chunk of engineers would tell you that they have build engineers or operations engineers who handle these things. In that world, this often entails generating an RPM file, spinning up EC2 instances, running things through continuous integration tools, and switching load balancers over to new machines. Not all of this will necessarily go away for a front-end operations engineer, but there will be new tools as well.

A front-end operations engineer will be a master of the build tool chain. They’ll help run and set up the continuous integration (or similar) server but, more specifically, they’ll set up the testing instances that their application runs on and then, eventually, the deployment instances. They’ll integrate Git post-commit hooks into the application and run the tests (either in Node.js and PhantomJS or against something like Sauce Labs, Testling or BrowserStack) before anything gets merged into the master. They’ll need to make sure that those servers can take the raw code and, with a few commands, build up the resulting application.

This is where many people use Grunt these days. With a quick grunt build, these machines could be serving the built version of an application in order to enable proper testing environments. The front-end operations engineer would be in charge of much that’s behind that command as well. grunt build could call out to RequireJS’ r.js build tool, or a Browserify process, or it could simply minify and concatenate a list of files in order. It would also do similar things to the CSS (or your favorite preprocessed CSS dialect), in addition to crushing images, building sprites and reducing requests in any other way necessary or possible.

Front-end operations engineers would make sure that all of this stuff works on people’s local machines. A quick grunt test should be able to build everything locally, serve it and test it (likely with some WebDriver API-compatible server). They’d make sure that team members have the power to push their applications into the continuous integration environment and test them there. And they’d remove single points of failure from deployment (GitHub being down during launch wouldn’t scare them).

They’d facilitate internal deployments of feature branches and future release branches. They’d make sure that the quality assurance team has an easy time of testing anything and that the managers have an easy time of demoing things that aren’t ready.

They’d help build multiple versions of an application to best suit each of their core sets of users. This could mean builds for mobile or for old versions of Internet Explorer, but all of it should be relatively transparent to those who are programming against those feature, browser or device tests.

They’d facilitate the process of taking a release, building it, uploading it to a static edge-cached content delivery network, and flipping the switch to make it live. And they’d have a documented and fast roll-back mechanism in place.

Perhaps most importantly, they’d automate everything.

(Image credits: Rube Goldberg)

Tracking Speed

The metric by which a front-end operations engineer would be judged is speed: the speed of the application, the speed of the tests, of the builds and deployment, and the speed at which other teammates understand the operational process.

A front-end operations engineer would live in a dashboard that feeds them data. Data is king when it comes to speed. This dashboard would integrate as much of it as possible. Most importantly, it would constantly be running the team’s app in multiple browsers and tracking all important metrics of speed. This space currently doesn’t have a ton of options, so they’d likely set up a private cloud of WebPageTest instances. They’d put them in multiple zones around the world and just run them non-stop.

They’d run against production servers and new commits and pull requests and anything they can get their hands on. At any given point, they’d be able to tell when, where, and what the surrounding circumstances were behind a slow-down. A decrease in speed would be directly correlated to some change, whether a new server, a diff of code, a dependency or third-party outage, or something similar.

They’d have a chart that graphs the number of HTTP requests on load. They’d also have a chart that tells them the Gzip’ed and minified payload of JavaScript, CSS and images that are delivered on load. And they’d also go crazy and have the unGzip’ed payload of JavaScript so that they can measure the effect of code parsing, because they know how important it can be on mobile. They’d instrument tools like mod_pagespeed and nginx_pagespeed to catch any mistakes that fall through the cracks.

They’d be masters of the latest development and measurement tools. They’d read flame graphs and heap snapshots of their apps from their development tools (in each browser that has them). They’d measure frames per second on scrolling and animations, prevent layout thrashing, build memory profiles, and keep a constant eye on compositing, rendering and the overall visual performance of the application. They’d do all of this for desktop and mobile devices, and they’d track trends in all of these areas.

They’d religiously parallelize tasks. They’d track the application via waterfalls and .har data to make sure that all serial operations are necessary or intentional.

They’d chart the average run time of the tests, builds and deploys. And they’d fight to keep them low. They’d chart their external dependencies in size and speed. They may not have control over slow API requests, but they’d want to be able to point to the reasons why their numbers are increasing.

They’d set an alarm if any of these numbers rose above an acceptable limit.

Monitoring Errors And Logs

Managing logging is a critical job of a normal operations engineer. The data that is generated from running an application is vital to understanding where things go wrong in the real world. A front-end operations engineer would also instrument tools and code that allow the same level of introspection on the client side.

This would often manifest itself as an analytics tool. Application engineers would be encouraged to log important events and any errors at certain levels to a logging service. These would be appropriately filtered and batched on the client and sent back as events to an internal or external analytics-style provider. The engineer would have enough information to identify the circumstances, such as browser name and version, application deployment version, screen size and perhaps a bit of other data. (Though they’d want to avoid storing personally identifiable information here.)

Logging stack traces can be very helpful in browsers that support them. You can integrate third-party services that do this for you.

The front-end operations engineer would encourage a very small tolerance for errors. Any error that happened would be investigated and either fixed or logged differently. With the data that comes back, they should be able to visualize groups of errors by browser or by state information from the application. A threshold of errors would be allowed to occur, and when that is passed, engineers would be notified. Severities would be assigned, and people would be responsible for getting patches out or rolling back as necessary (with quick patches being heavily favored to roll backs).

Much like today’s operations people focus on the security of the systems they manage, a front-end operations engineer would have probes for XSS vulnerabilities and would constantly be looking for holes in the app (along with the quality assurance team).

A front-end operations engineer would have an up-to-date picture of the state of the application in production. This is challenging in the front-end world, because your application doesn’t run on your machines — but that makes it even more necessary.

Keeping Things Fresh and Stable

My favorite thing that good operations people who I’ve worked with in the past were really good at was keeping things up to date. For some applications, stability and security are so deeply necessary that caution is the larger priority; but in most cases, failure to keep dependencies and environments up to date is what causes applications to get stale over time. We’ve all worked on a project that’s four years old where all of the tools are very old versions of the ones we know, and getting good performance out of it is impossible.

A front-end operations engineer would be effective at keeping dependencies up to date and at removing cruft in systems. When the next version of jQuery is released, they’d use their skills to switch out the dependency in the application to work with the new version and then test it to validate the change. They’d keep Grunt up to date (and Node.js along with it). When WebP becomes viable, they’d automate moving the application’s images over to that format.

They’d work closely with the more architecture-oriented application engineers to make sure that the entire system still feels viable and is not lagging behind in any one area. They would keep on top of this stuff as often as possible. Updating a dependency here and there as you build is far easier than having a big “Update Everything” day. It encourages application developers to loosely couple dependencies and to build good, consistent interfaces for their own modules.

A front-end operations engineer makes it viable and fun to work on a project long after it’s new.

The Future

I’m sure plenty of commenters will tell me that these tasks have been going on for years, and plenty will tell me that they should be the concern of all developers on a team. I would agree with both statements. I am not introducing new concepts; I’m compiling tasks we’ve all been doing for years and giving them a name. I think this will help us build better tools and document better processes in the future.

The addition of this role to a team doesn’t absolve the other members of performance responsibilities. It’s just that right now, front-end operations are no one’s explicit priority on most of the teams that I’ve encountered, and because of that, they often get skipped in crunch time. I think there’s enough to be done, especially in the configuration and monitoring of these tools, outside of the normal job of a front-end engineer, to justify this role.

Most importantly, regardless of whether a new job comes from these tasks, or whether we solve the problem in a different way, we do all need to be conscious of the importance of solving these problems in some way. You simply can’t ignore them and still achieve reliable, robust, high-experience applications. Addressing these concerns is critical to the stability and longevity of our applications and to the happiness of programmers and users.

If we build with that in mind, it helps the Web win, and we all want the Web to win.

(al) (il) (ea)

© Alex Sexton for Smashing Magazine, 2013.