At Mobelux, the development projects never stop. We’re constantly working on both new and existing codebases. At any given time, there are multiple versions of Python, Ruby, NodeJS, PostgreSQL, MongoDB, and Elasticsearch all in active use.

With all these different environments running our code, it can be incredibly painful to ensure that each development and testing environment is configured to use the correct versions of software and daemons. All of these moving parts can also make it difficult to ensure that deployments to production environments happen consistently and correctly.

To simplify development and deployments we started using Docker and Docker Compose, and they’ve made our lives so much easier.

Docker Basics

In case this is the first you’re hearing of Docker, I’ll give you an overview of how it works.

Docker allows you to quickly and easily set up complex environments in a consistent, reproducible manner. It gives your software a small, isolated environment called a container which is completely independent of the other software running on your computer or in other containers.

These containers can then be configured to run any operating system and install any necessary software, allowing you to easily configure application-specific needs without affecting other software that may have conflicting needs. It’s similar to a virtual machine in many respects (for those of you more familiar with that technology) but uses far fewer system resources to run.

Each Docker container is an executing instance of a Docker image — a pre-built definition with all the software and configuration built in so it runs exactly the same everywhere. The image itself is built from a text file called a Dockerfile that contains a simple list of commands and can be consistently rebuilt whenever necessary.

That means that once a Dockerfile is created, any user can quickly build an image from it and run a container that’s pre-configured with the correct software. You can also pre-build and distribute the image to save even more time.

As you probably know, most web applications and APIs consist of more than just one application. They make use of databases, caches, and other web services running on other servers. Docker Compose is a tool that’s distributed alongside Docker and comes pre-installed with Docker for Mac and Docker for Windows, allowing you to define a group of containers that all start up together and run on a private network. That way, you can simulate the entire production stack in a local, isolated, automatically-configured environment.

Developing with Docker

When you’re working in a traditional development environment for a web platform, a developer has to configure a number of things and keep them all in sync as the platform evolves. First, the correct environment (such as a specific Python, Ruby, or NodeJS version) has to be installed. This alone can be time consuming, error prone, and just a lot to handle for someone new to the ecosystem — especially when you add in tools for segregating environments and libraries for multiple projects to exist on the same machine.

Next, the developer needs to ensure that they have the correct versions of external services such as databases and caches. If you’re working on multiple projects, you could need several versions of each, and you have to keep them up to date with whatever you use in production. Each project could also need any number of development libraries and system tools to properly build and run. Without something helping you out, the whole thing can be extremely difficult and time consuming.

That’s where Docker comes in to save the day.

Using Docker, we only have to configure everything once and then distribute it as a Docker image. Whenever a developer works on a project, they pull down the latest image or rebuild it from the project’s Dockerfile. This automates the installation of the correct versions of all software dependencies so that we can be sure everything is correct and up to date.

By using Docker Compose, we take it a step further by configuring images and containers for the correct database, cache, search engine, and even an Amazon S3 clone. We configure these compose stacks so that when started, all services start up, a local copy of the current code is mounted into the development container so that the developer may use native code editors and tools of their primary OS, and the developer is given command line with the ability to install any release specific dependencies and run the development code.

At the end of the day, this saves us hours of work configuring systems and debugging configuration problems. Setting up an environment for the first time will takes minutes (or even seconds) instead of hours.

As an added bonus, bugs throughout the lifetime of the project are reduced because development is happening using the same libraries, base OS, and external services used to run the production systems. Updates to any of those services and dependencies can also easily be tested locally so you’re sure they’re working as expected.

Testing with Docker

After development comes testing, where Docker continues to be the go-to tool to make the process simpler and more accurate.

All of the same challenges with development still exist for testing and can even be compounded when not all testers come from a development or highly technical background. Docker gives us a couple of different options for managing this complexity.

A developer can provide the docker image with the correct version of the code already baked into the image. This way the tester doesn’t need to interact with version control or check to make sure they have the correct version of the code locally. Then Docker Compose can be used to run a container using that image along with containers for external services so they can simply run the Docker Compose stack, and everything is right there.

If we do need to test specific code from version control, the tester can still do that by cloning the git repository and having it mount in to the running container similarly to the development process. The difference is that rather than going to a command line, the container with the code that needs testing automatically installs the current dependencies, seeds the database with basic test data, and automatically runs the service.

To make it even simpler we’ve been using a tool called Lifeboat — a simple GUI for Docker Compose along with GitHub Desktop. This allows testers to easily start and stop compose stacks without the need to navigate between projects or manage Docker and git on the command line.

Deployments with Docker

It’s finally time to deploy and Docker continues to make things easier.

In a traditional server deployment, each server has to manually update dependencies at the time of deployment. For most modern web platforms built with languages such as Python or Ruby, this means reaching out to external servers to download those dependencies and, in some cases, compile them each time. Every time that happens, there’s another chance for a failure — especially considering that the server operating system might be different from where development or testing took place.

When using Docker in staging and production environments, those risks are reduced or removed. We first create an image and deploy it to staging to make sure that it builds, deploys, and functions as expected. This exact same image, which already has all of the dependencies installed and configured, is then be deployed to production removing the previous opportunities for failure during deployment.

From development to deployment, Docker makes the life of a developer so much easier and less frustrating. I highly recommend you give it a try.

Reducing Complexity With Docker was originally published in Mobelux on Medium, where people are continuing the conversation by highlighting and responding to this story.

I first went to SXSW in 2009, the year Foursquare launched. I say that not for street cred (digital cred is worthless on the streets), but to date myself and the environment.

At the time, I worked in the digital division of a traditional media & broadcast company, and they were dying. I think it was the second round of furloughs that “awarded” us with an extra 10 days of (unpaid) leave that made me realize if I didn’t become the change I wanted to see in the world, I’d be left in the cold alongside their dwindling classifieds section.

I snagged an Interactive ticket from Craigslist (under $400 if I remember correctly) and pulled favors from my Austin friends to sleep on an inflatable mattress for the week. At the time, I didn’t know anyone going to SXSW during the tech week. Everyone asked which bands I’d be seeing and were uninterested when I told them about meeting a guy named Gary V. who sold wine through twitter or the Bobblehead I got from the founder of Reddit.

When I last attended in 2015, it was clear the game had changed. It had become a constant battle to fight the noise, and I left both fulfilled and exhausted. Startups had inundated every surface with their stickers, posters, and swag. The start-up parties of yore were now exclusive VIP events with little room for anyone not on the list. While there were tons of free sessions sponsored by brands like Samsung, CNN, and Fast Company, they also now had the long lines that permeated all of the popular badged sessions. It was a constant scramble to find the next quest before the current one ended, and considering half of the time it ended in tacos, it was well worth the journey.

So, you still want to go to SXSW in 2018? I do too, and here’s what I suggest:

1. Get a badge — It’s still the best way to see the conference, especially if it’s your first time. You’ll have hundreds of sessions to choose from, and even if you or your corporation pays a premium (currently $1325) for the ticket, you can count on at least a few hundred of that being offset with coffee, taco, and beer happy hours. (If you don’t have a badge yet, seriously, check Austin-Craigslist for last minute cancellations.)

2. Don’t sleep — Wake up early. This has been the underlying advice for every year. There’s so much to see and do, and with well-placed coffee breaks throughout your day, you’ll keep the party going. There are plenty of planned and spontaneous meet-ups at breakfasts before the sessions start and some around 11pm when those who aren’t going out to party all night peel off and find their way to late-night tacos (Chi’lantro or Torchy’s). You can find meaningful connections at SXSW, but not if you’re asleep in your hotel room.

3. Avoid the elites — You’ll quickly pick up on some people who think they’re better than you, move on quickly.

4. Don’t drink (to excess) — This may be based on personal preference, but I think if you’re looking at SXSW as a chance to let loose, there are better ways to spend your time. Sure, there are happy hours from noon till night, but in order to keep up a grueling schedule (and to get a leg up on your peers who may over-indulge), take it easy with the partying.

5. Make new friends — You could spend the entire conference rolling with your strategy team, but then you’d all end up with the same experiences and little to show for it. I’d suggest not going with more than 1–2 friends at a time, and always look for opportunities to make new ones. You never know who you might end up having dinner with.

6. Say yes — This improv comedy mantra has served me well at SXSW. I’ve met tons of great people and had unforgettable experiences by saying yes to something I’d typically be adverse to (like karaoke, don’t get the wrong idea).

On-the-ground tips:

• Skip the keynotes. They’re live streamed, can be found later, and you’ll waste hours in line waiting for them to start.
• Target who you want to meet up with, find a quiet cafe, and slide into those DMs. Most people I’ve found are flattered that you appreciate their work and would happily meet with you.
• Try to get to the East Side. It may be completely overrun by now, but for a while, the events and venues on the East Side were a bit less of a mess than the convention center and Sixth Street. You’re also more likely to meet locals willing to share a slice of their Austin with you while waiting for food trucks at the end of the night.

• Hit the Interactive Awards. Typically the food is decent, the crowd is light, there’s a good comedian, and you can meet a bunch of people over dinner. Slip out if it runs long, but it’s a good in-between time and saves you from running out to another dinner.
• Say yes to free food. Some of the best spots will be giving out free food thanks to how out of control the marketing has gotten. Keep your eyes peeled, and save some cash.
• With that saved cash, treat yourself to an escape meal. Take an evening, find a spot you really want to try (Elizabeth Street Cafe is mine), and either invite someone for a 1–1 dinner, or take yourself. It’s amazingly restorative.
• Happy Hour at Hotel San Jose is also always a good escape from the madness.

Rest up, plan well, and have fun. Now I’m wishing I was going with you.

If you must go to SXSW was originally published in Mobelux on Medium, where people are continuing the conversation by highlighting and responding to this story.

It’s very seriously one of my favorite things to do. In that situation, two people are forced to be completely present and focus on the story at hand. Even though you might have to yell over the table or repeat yourself over and over, if it really matters to you, you’ll put in the work to tell your story.

Storytelling and photography are two things I’m very interested in exploring, and I’m thankful to be a part of hosting a Mobelux event that brings them together.

Mobelux has an incredible space at our disposal. Saunders Station is a renovated federal post office building built in 1937 and located in Richmond’s historic Fan District. When we moved in, a spark ran through our company culture, and we knew we had to use the space to bring people from our community together whenever possible.

Once a month, the Mobelux production team invites two photographers to come share a story about some of their work. Tickets are available for free to the public, and we’re so grateful to the people who have come out so far.

The event is simple enough:

• 30 minutes of hanging out and networking
• Presentations from two photographers on a selection of their own work
• Q&A at the end of each presentation
• 30 minutes of more networking to talk about the presentations

Part of the wonder of walking through a museum is trying to understand the mindset of the artists who create the pieces — discovering how they see what they create. Photo Night is an opportunity to hear about that mindset, and have a conversation with an artist face to face.

At our second photography night for July ’17, we invited Casey Templeton, an award-winning commercial photographer, and Will Godwin, senior designer at the Martin Agency, to join us and present their work.

We asked them to talk about whatever work they were most interested in — it didn’t have to be their biggest project or most well-known photograph. Photo Night is all about the passion and the story behind the work more than the work itself.

Casey presented a series of pigeon racing photographs he took while interning at National Geographic. He has a huge portfolio full of commercial and corporate work, and it was pretty amazing to hear him talk about work he did before all the success came his way.

Will was up next. He has an eclectic portfolio largely created while establishing the art direction at Need Supply Co. but presented polaroids and 35mms of his friends and family. He sees photography not only as a profession, but as a way to document his relationships and express love.

For Casey, photography is serious work. He’ll talk about the business side of photography with anyone. His photos are finely tuned and always keep the client’s wants and needs at the forefront. Will spoke about photography as an intimate expression. If we hadn’t asked him to, Will might have never shown these photos to anyone outside his friends and family. They were presented as they were shot — simply and purely. When asked about the intent behind each photo, Will rarely said more than, “that was a fun day” or “he had a good smile”.

These differences are part of what makes Photo Night such a dynamic event, and it’s part of why it’s become so important to us.

We realized how truly valuable it can be to bring two artists with complementary styles together to support and learn from each other. It made for a dynamic, engaging event for the audience, and we decided to intentionally choose photographers with contrasting styles moving forward.

Starting with Will and Casey’s night, we have found ourselves in the company of two gifted photographers every month from then on. Each one bringing their own unique language, and letting the audience discover their similarities.

I want to take a second and say how grateful I am to everyone who’s attended the events so far. They’ve given Photo Night a life and an energy beyond what we could’ve hoped for. They’ve turned the Q&A portion into a stimulating, inspiring conversation that speaks to the event’s central idea — that the message behind the art is just as (if not more) interesting and worth talking about as the how-to’s and the commercial successes.

We hope this exchange of ideas between audience and photographer creates growth in our community and changes how people look at photographs or even take their own.

I loved seeing a side of these established photographers that they don’t normally show, and I definitely walked away feeling inspired.

I see it all as a chain reaction.
The food photographer inspires the meticulous side of the fine art photographer > who makes the architectural photographer think differently > who inspires the editorial photographer to work with more lines > who inspires the documentarian to compose in a more ornate way > who inspires the studio photographer to carry their camera around with them more often.

I hope you can join us at the next Photo Night.

Sign up for the Photo Night email list.
Follow Mobelux on Facebook for notifications on all of our community events, and check out our Instagram for pictures from past events.

The Mobelux Photo Night was originally published in Mobelux on Medium, where people are continuing the conversation by highlighting and responding to this story.

2017 was a quite a year for Mobelux. Though it marked our ninth year of operation, in many ways, it felt like our first.

Moving into our own place definitely made everything feel new again, but I think the root of that feeling is that each year we keep learning so much more about what we need to do to thrive in this industry. When you get down to it, that’s really our central goal: never stop improving on what we do.

Saunders Station is Our Home

2017 was our first full year working out of our new space, a historic 1937 renovated post office building in the heart of Richmond. It’s strange how quickly the building has become an real expression of who we are as a company.

When you walk through the building, it’s all about the details — the historically appropriate fonts, the modern touches, the old P.O. boxes, and original vault. If you look closely, you’ll even noticed repurposed metal mesh in interesting places around the building. The Julien Binford mural is our standout piece. It speaks to the rich, complex history of our city and reminds us of how much has, and hasn’t, changed since it was made.

Our building was featured in a few local articles, including one solely about the mural, and we were pleasantly surprised to pick up a good amount national coverage as well. Uncrate called it “lovingly renovated” and a reflection of a “workplace that pays respect to and yet builds upon what came before — just like any good product.”

Dwell picked Saunders Station as number five on their Top 10 Offices of 2017 and noted how we turned the building into a “contemporary office, while also embracing its charming architectural details and historic narrative.”

To finish off the year, we ended up being awarded the Golden Hammer for Best Adaptive Reuse — Large. They noted “this is the modern, technology-infused workplace of the future!”

We kicked off three reoccurring groups with Women Who Code, React JS, and a Photographer’s Storytelling Night. Michael Graves Design and Rob Van Varick also came in to host a town hall style event where they talked about “Designing the Future of Intuition.” We all left inspired and can’t wait to host more events in the future.

We couldn’t be more proud of how the building turned out. For us, Saunders Station is about more than just a nice building. It’s about connecting to the community that supports us and giving our employees a place they actually want to spend their time.

Supporting Our Partners

In 2017, we found ourselves traveling and supporting partners in places we never dreamed we’d be. We joined World Pediatric Project on a trip to St. Vincent, documenting the incredible work they’re doing to change the lives of sick children in need. It’s impossible not to be proud and honored to work with people who affect real change in the world and are so passionate about the work they do.

Another memorable moment was when we went to our nation’s capital to interview and photograph members of Congress with Montpelier’s Robert H. Smith Center for the Constitution.

Our business is in building meaningful experiences, and it’s moments like these that help us remember what that truly means.

Strengthening our Partnerships

Twenty-four new partners joined our client list in 2017. Without them, we simply wouldn’t be here, and we’re grateful for the trust they’ve put in us. In 2018, we hope to continue to stand by their side and help them thrive, building longterm partnerships that benefit us both.

The products we built spanned across industries, form home, fashion, and food to insurance, medicine, and art. Everything we did centered on building meaningful experiences, and we’ve grown with each project.

Look for some more in depth features over the next few months highlighting the work we’ve done for our partners.

New Employees

Mobelux employees make us what we are. I’m so lucky to work with such talented and driven individuals, and I’m grateful to all of them for the work they do here. In 2017, we were thrilled to welcome Jim, Will, Kathleen, Ellen, and Terrill to the team. They’ve already made a great impact on our company, and it’s a privilege to have them working with us.

Webby Award

Our work with The Infatuation earned us a 2017 Webby Award in the best Mobile Site & App in the Food & Drink category. In our world, winning a Webby feels a bit like winning an Oscar, and it speaks to the quality of work coming out of Mobelux. There’s nothing better than seeing our partners succeed, and knowing we were a part of that is pretty incredible.

Here’s to a great 2017 and an even better 2018 — after all, we turn 10 this next year!

Mobelux 2017: a year in review with an eye to the future was originally published in Mobelux on Medium, where people are continuing the conversation by highlighting and responding to this story.

At Mobelux, one of our key goals is to support and champion our partners in whatever way we can. When I heard that our long-term clients iHome and Ford were going to have a presence at this year’s Consumer Electronics Show (CES), I found myself getting up at three in the morning to jump on a flight to Vegas.

This was my first time at CES, and I was curious to see what I would learn from such a massive event.

It was a crazy, jam-packed two days.

CES is the largest technology show in the world, and this year’s was the biggest in its 51-year history, with close to 4,000 exhibitors covering more than 2.75 million square feet across Las Vegas. This is the tech event of the year, where the latest technology companies showcase their vision for the future — everything from smart cars to robotics to the newest thing in televisions.

I wanted to experience CES through our clients’ eyes, looking out for anything that could benefit them (and Mobelux, of course) in the coming year.

What did I learn?

1. Never forget about Google. The big brands are competing. I mean seriously competing. Amazon, Apple, Google, Facebook, and a few other players are constantly looking to stake their claim in defining how we connect to the world. Google made the entire city of Las Vegas feel like it belonged to them. From the moment you stepped off the plane, their brand was everywhere. Big displays on all forms of transportation, integrated products within the booths, and what seemed like thousands of Google employees sporting their t-shirts.

My immediate takeaway is that we can’t afford to forget about Google Voice. Voice integration should not just be looking to Amazon’s Alexa for immediate implementation. There were quite a few Google Voice products featured with other companies at the event, and it’s clear that Google is not going to concede to Amazon anytime soon. I’d look to Google to make some significant growth in the market over the next 12 months.

2. Augmented and Virtual Reality are Here to Stay. Augmented Reality (AR) and Virtual Reality (VR) tech was everywhere this year. Experts predict that the AR and VR industry will make over $1 billion this year alone, and seeing all the companies (taking up a total 45,000 square feet on the floor) vying for everyone’s attention and money was intriguing, to say the least.

I’m personally more interested in AR at the moment, but the idea of putting my face into the same headset as thousands of other people was enough to stop me from actually trying the new products on offer.

From a business perspective, it would be crazy to ignore VR and AR. That industry is going to explode in the next three to five years. Start paying some serious attention to these technologies in the next 12–36 months, and think creatively about how they can benefit your company. Just watch — it’s going to affect so many areas of our life — medicine, design, education, entertainment, and more.

3. Being connected has its advantages. Smart cities were a big topic at the conference sessions. Ford had a large, compelling Smart City display aligned with their version of a smart car. It may still be a while before we get to experience an actual smart, connected city, but our homes could be a different story. Multiple companies are offering a variety of easy integration points that we can start playing with in our homes.

We’ve heard for a long time about smart thermostats, lightbulbs, and sensors for the house, but now the products are finally becoming widely available through mainstream vendors like iHome, and with voice products like Google Voice and Alexa, it won’t be long before you start seeing your neighbors’ homes become more and more “smart”.

My recommendation? Get a Google Voice or Alexa product now, and pick up a smart plug or two while you’re at it. Start by connecting your music or your favorite lamp, and learn how fun and easy it can be to have these connected devices around you. That way, you’ll be ready for your next big thing: a connected car.

You don’t need to think about getting a smart car just yet — more immediate next steps are found in vehicles that make your existing technology easier to use and access within the car. Apple CarPlay and Ford’s Smart Device Link (SDL) are going to make your commute way more enjoyable, and they’re coming at you very soon. For me, sitting in a car and having Waze run and display inside the car monitor instead of on my phone was already a huge improvement.

4. Your next TV needs to be the LG OLED TV. Seriously, start saving your pennies now. LG is killing it when it comes to making beautiful TVs. Your family will gather around this TV with their mouths wide open. Life is meant to be experienced at a high level, and yes, that now means a big beautiful TV. Ok, ok, I’ll admit I’m pushing a bit in case my wife is reading this, and I know that this isn’t completely groundbreaking news to many of you, but luckily the curved TV fad is over. Clear beautiful OLED displays are now becoming affordable at a great size. (Well, affordable compared to last year, that is.)

The LG booth was honestly my favorite. It began with a curved walkway with walls that had to be 20 feet tall, displaying stunning footage was nothing short of incredible. It’s displays like this that make CES so different from any other shows. It feels like you’re stepping into the future. LG — just go ahead take my money.

5. Nikon is still my favorite camera brand. Nikon truly set themselves apart from the crowd. They kept the focus on being human, not robotic. In the middle of their showroom, Nikon set up a stage and invited some incredibly talented photographers to teach and inspire us in-person. I couldn’t believe it when I saw Joe McNally — one of my all-time favorite photographers — take the stage to share an amazing story about how he pulled off a recent shoot. It was refreshing to see a group of individuals at a tech conference engage so fully with an actual person instead of with a piece of tech. It reminded me how important and powerful it is to share human experiences with each other, and it was truly a standout event of CES.

The last item, which didn’t make my top five but still makes me chuckle when I think about it — the selfie drone. Be prepared to kick that selfie stick to the curb and get those angles that only a drone can provide.

In closing…

Google seriously knows how to market.

If done right, AR/VR will have a huge impact on your business.

Get started on your connected home now.

Don’t forget that human connection will always stand out.

Start saving for that new OLED TV today.

Reach out and let me know if you went to CES this year — or if you’re planning on making the trip next year. I’d love to hear some of your takeaways and compare notes.

5 Takeaways from CES 2018 was originally published in Mobelux on Medium, where people are continuing the conversation by highlighting and responding to this story.

iHome is an electronics company that Mobelux has done a variety of work for over the course of eight years. They’ve given us the opportunity to build a vast portfolio of apps and web platforms, and in 2015 they hired Mobelux to provide product photography.

For years, iHome had gotten by using in-house, stock, and rendered image solutions, which allowed them to keep their photographic process simple. But to elevate their online representation, they asked us to produce imagery that was aligned with the flagship website that Mobelux had recently built.

Mobelux got to work photographing iHome products, both in studio and in lifestyle environments, that could be used across a variety of platforms. For the studio photography, iHome wanted their products to represented in a clean, clear way so customers could easily take in every detail of the product. We photographed the iHome products against a crisp white background for consistency and clarity, and then offered a deeper examination that would focus on product design.

Establish a visual identity for the brand

iHome products vary from the bedside clocks that they’re best known for to smart home accessories, beauty mirrors, color-changing white-noise machines, and more.

Mobelux identified the features that these products all had in common and found a way to consistently represent them for the brand while simultaneously highlighting what sets each product apart.

We also decided to offer alternative, detail-focused images for each product. iHome’s eye-catching website set the foundation for our approach to creating the imagery.

Inspiration

Haw-Lin Services, a creative studio out of Berlin, approaches detail photography with intricate curiosity. Trained as graphic designers, they focus on the compositions that can be made from the many shapes in colors found in each object. Photographed in a deep depth-of-field, the various shapes are often all in focus, and the attention is placed on the unique characteristics of a product’s design.

We initially established a commonality for all iHome products by smoothly lighting every item on a clean white background. After making sure we captured each angle clearly, we then applied the new, detail-focused approach to highlight the products’ unique characteristics.

A bonus of photographing this way is that we were able to explain the features and capabilities of iHome products more clearly than when we photographed them in literal, real-life scenarios. Most of their products have a number of features, and using detail-focused, in-studio photography allowed us clearly explain the device capabilities without resorting to a lifestyle shoot.

Take the iBT372 for example. It’s a lightweight, portable, bluetooth speaker that is shock, dust, and water resistant, meaning it can be used when camping, kayaking, or relaxing on the beach. It also has a color changing feature that gives it a great look when using it outdoors at night.

Another example is the iHome iZBT5, a portable ambient noise/bluetooth speaker with soothing sounds and colors. We performed the same exercise, using detail-focused photography to highlight the product’s soft texture and its ability to change to a color that symbolizes whatever ambient noise you choose.

Because we photographed the products in our studio, we were able to conceptualize, photograph, edit, and ship these images at a faster pace than using lifestyle images.

Lifestyle

Typically, lifestyle photography is visually busy — using an abundance of props in order to attract a specific customer. Too many lifestyle photos can very quickly consume a single page, which will only distract from the central message a brand is trying to convey.

Inspiration

We applied a fashion photography aesthetic to our lifestyle shoots – using a large, soft, single-light source and then stripping down visual elements in order to make sure everything in the frame enhances the product.

Styling

We wanted to start with as blank a canvass as possible so we could curate the space surrounding the product to meet our needs. We chose the locations carefully and built a scene that would align with the look and feel of the website and the in-studio images.

We wanted to remove clutter from the iHome site and give the viewers images that are easy and pleasant to process. For our purposes, models are primarily scenic elements of the photos. They evoke a look and sell the use-case, but the focus is always product-first.

Lighting

On previous shoots, we were lighting the images based on the individual elements within them — background, foreground, product, and the model. The updated approach, using minimal light sources to fill the environment, made the set up time for lifestyles much faster and gave each image a more refined, manageable color palette.

Results

Our images are no longer relegated solely to a supplemental photo in a product listing. They are now integrated into the website to provide a polished, visually-consistent aesthetic to the iHome shopping experience.

Additionally, iHome spreads these photos throughout Instagram, in-store displays, and trade shows like CES. They can stand by themselves or, like the detail images, amongst other imagery to tell an in-depth story and represent the brand in a consistent, beautiful manner.

Pulling a Brand into Focus was originally published in Mobelux on Medium, where people are continuing the conversation by highlighting and responding to this story.

As a front end dev, you’ve been familiar with styling and building layouts for your sites and applications in the way of the web — using good ole’ CSS and HTML. However, when you dive into your first React Native app, you’ll notice things just aren’t the same — may even seem a bit strange. Divs and spans ? Gone. Traditional CSS? Nope. But don’t panic! Everything is going to be okay… because hey, it’s just JavaScript.

1. Styling is done using JavaScript

As a modern day front end dev, surely (er..hopefully) you’re familiar with JavaScript. Great news! That’s all you’ll need to style your React Native components! Really, your components are essentially just functions, and you’ll style them using JS objects. Although you’ll never use CSS syntax, JS style property names will mostly match what you’re used to with CSS. The primary difference however is that JS styling uses camel casing. Also, some components won’t accept certain style properties ( ex: <View /> can’t take a color prop ).

CSS:

.bg--slate { background-color: #252525 }

JavaScript:

bgSlate: {
   backgroundColor: "#252525",
}

2. Styles are scoped to their components

In the web world, your styles are scoped to the browser — with RN, it’s scoped to the component. The beauty about this is that you never really have to worry about conflicting styles throughout your application. Bad thing is that there are really no concept of selectors. You have to create your style, then apply it to any and every component that needs it.

base.js

fcWhite: { 
   color: "#FFFFFF", 
}

MyComponent.js

import base from "../base";

<Text style={base.fcWhite}>Christian Bryant</Text>
<Text style={base.fcWhite}>Loves React Native</Text>

3. Programmable

Remember when I mentioned that everything you do is in JavaScript? With that being the case, you are able to take full advantage of the language — your styles are completely programmable.

const lighten = (n) => `rgba(255,255,255,${n})`

console.log(lighten(1/2));  // rgba( 255,255,255,0.5 )

4. Fewer options compared to CSS

1. Measurement units are all in pixels
2. Some properties you’ve used in CSS don’t exist ( like transform origin )
3. No media queries ( but you can use the dimension object to check for viewport size)
4. No display rules - layouts are all built using flexbox

5. Some extra tips

There a few other things to keep in mind when going about styling your React Native app. First, have a base style sheet. For shared styles it’s always a good idea to have a common base to go from that you can import to other stylesheets or components with.

Next, your UI components should encapsulate their own specific styles. This is important for when it comes time to update or refactor your component, you don’t have to worry about side effects throughout the rest of you app.

Lastly, make your components as reusable as possible. For example, say you have two variations of buttons in your app. One is blue, and one is red, but everything else like border radius, width, and height are all the same. Instead of creating a ‘redButton.js’ and ‘blueButton.js’ component, create a single button component and just pass the color in as a prop.

Transitioning from styling for the web to React Native can feel a bit strange, but I hope this quick read helps you feel a bit more comfortable, and that you can take away something to apply to your first project. At the end of the day, remember, it’s just JavaScript. If you have any further questions or feedback you can find me on twitter @rvawebd00d.

5 Things to Know When Styling Your First React Native App was originally published in Mobelux on Medium, where people are continuing the conversation by highlighting and responding to this story.

“How much would it cost to make this [app/website/product/widget]?”

It’s a question I get asked a lot, both in personal and professional settings—a perfectly reasonable one.

Unfortunately, there’s no magic formula or cheat sheet I can give you. There aren’t any one-size-fits-all solutions—at least none that I would recommend. In order to give you an accurate answer, I need to know a lot more about your concept, your constraints, your requirements, and your wildest dreams for the product.

At Mobelux, we call this a Discovery Phase, and I see it as the natural first step in bringing any idea into the world.

So when you ask that question, you’re probably not going to love my initial answer, which is usually “I don’t know,” followed by a long-winded analogy about cars (more on that in a bit). But first, let’s take a trip down Memory Lane…

Ages ago, I worked in various retail positions for a well-known computer company. Culturally, it couldn’t have been further from the stereotypical “sales” job, and, contrary to most of our customers’ assumptions, we didn’t work on commission. We were encouraged to spend as much time with our visitors as possible, whether they intended to buy something or not.

As a result, I got to know people. I got to talk to them about how they wanted to use the computer. I got to help them make slideshows and burn their home movies to DVD. I exposed them to new worlds made available to them through technology.

I sold a lot of computers in my day, but never felt pressured from my higher-ups to sell something to someone that wasn’t exactly what they needed or wanted. At the center of this sales approach is a philosophy that shaped my approach to software design and client services: It’s OK to say “I don’t know” as long as it’s always followed by “let’s find out.”

What I love about “let’s find out” is that there’s an implied sense of collaboration, problem solving, curiosity, and empathy. It’s also a good exercise in humility. I never had to feel bad about getting stumped. I never had to make something up to sound more like an expert. All I needed was the confidence that I wasn’t alone—that I could use all the resources at my disposal to arrive at not only an answer, but the best answer, together.

It’s a great lesson to teach a twenty-something know-it-all (like I was), but it’s an even better one to apply to any collaborative work environment. Because if you lose that curiosity, close yourself off from your clients and teammates, or start trying to find problems that fit a solution rather than the other way around, you’ve set yourself up for frustration, conflict, and even failure.

Back to that car analogy I mentioned.

It works because software can be a costly investment. A lot like buying a car. You can get an affordable car just like you can get an affordable app. You can show off with your limited-edition Ferrari, but you’re going to pay for that privilege.

So, you come to me, your friendly neighborhood car salesman, and say, “Hey, I need a car. Which one should I get, and how much is it going to cost?” I think anyone can see how that’s a difficult question to answer. I don’t know anything about your constraints (budget), your requirements (the four kids and a dog you need to transport), or your goals (0–60 in under 5s). Without that foundation, I can only give you a comically unhelpful range, like “probably somewhere between $10,000 and $100,000, but maybe a lot more.”

So, like any good car salesman, I start asking questions to figure out what kind of car you need in order to provide a more accurate cost estimate. I’m not going to pick a car off the lot and convince you that it’s perfect for you. I’d rather not sell you a car than sell you the wrong one.

The quickest way to start narrowing things down: “Do you already have a budget?”

It’s OK if the answer is “No”. Maybe you don’t know yet. Maybe money is no object. Either way, that’s still information we can use. I know it seems aggressive to ask about budget right away. I just need to figure out if you are looking for a Civic or a Ferrari.

All those kids…do you need a third row? OK. You don’t see yourself driving a minivan? Got it. Your favorite color is yellow? Cool. As I learn more, I’m building a mental model of your ideal car. Then I’ll try to match that as closely as possible to something on my lot. It’ll be a lot quicker now that I know you’re looking for a yellow SUV with a third row for under $40K.

And that’s where the analogy falls apart — but, in this case, the failure of the analogy is almost as helpful as the similarities. The difference is, in our business, pretty much anything is possible. We’re not constrained by inventory or manufactured solutions. Instead, our constraints are usually just time and resources.

So how do we avoid the trap of jumping right into a solution before knowing the problems you’re trying to solve?

Well, first I need to understand those problems. Only then, with a common goal and mutual understanding, can we get to work on answering any of your questions with conviction.

At Mobelux, we do this Discovery Phase for every project. It’s more than just research. And it’s not just about coming up with better cost estimates. It’s about coming up with a better product.

Every product is made up of the answers to hundreds, even thousands, of questions: How can this product succeed in the market? Who is going to use this product? How much will it cost to make and maintain? What’s the right font to use? Does this color have any negative associations in other cultures? What technology stack should we use? Does this interface make sense to our users? You get the idea.

Once we know (or think we know) the answers to some of these questions, we also need to understand our constraints. What about your expectations for the product? The expectations of your users? Does this product need to fit in with an existing ecosystem of related products?

All of these answers form our basic assumptions about the potential solution. Each assumption needs to be tested, validated, and revised. We learn from every failure and celebrate every success, improving our solution with every iteration.

The process of validating and testing these assumptions results in a variety of artifacts and deliverables — scope documents, user interviews, wireframes, prototypes, or brand guidelines — all of which aim to push our solution further, closer to our end goals.

This is our discovery process. This is how we make products — and make them better. Through collaboration and teamwork we attempt to answer these questions, challenge our preconceived notions and assumptions, and empower everyone involved with the simple notion that it’s OK if you don’t know the answer.

Because together we can solve anything.

Anatomy of a Discovery Phase was originally published in Mobelux on Medium, where people are continuing the conversation by highlighting and responding to this story.

People like me, those with some gray in their hair, will spot this as a rehash of a previous strategy, but this time, thankfully, the technology is finally ready to properly support it.

History

Back in the early days of the web, just about all sites were static. The result of “making a website” was some HTML/Images (and CSS, once that came around) that could be put on any web host. It looked roughly like this:

Back then, when we wanted to do more with a site (templating, form submission, changing data, and admin), we needed a system that ran scripts on the back-end. CGI with Perl was the first interface there, but it soon evolved and improved from that. We developed stacks of technologies, one of the most popular being the LAMP (Linux, Apache, MySQL, PHP) stack. This allowed for database-driven websites whose content rendered from data in the database when requested. A large percentage of websites out there today are based on the LAMP stack based Wordpress, which was an early database-driven platform for content on the web.

It looks roughly like this:

Note: Mobelux is not a PHP shop, the LAMP stack is being used as a reference because of its popularity. Our backend code is mostly written in Python, Ruby, or Javascript.

The Problem

The issue with these database-driven sites (like those built on Wordpress) is that the extra moving parts can each individually break and kill your entire website.

While Wordpress has dramatically improved its security, you used to have to update your install every month or you would get hacked. You would then have to call people like me, who would have to spend way too much time fixing it.

Those are the dark days we try to forget.

Additionally, if you were lucky enough to get a post or page shared on a popular site that would get you a lot of hits, your web server (running PHP) and/or your database would completely fall over. A lot of work went into being able to scale this type of platform: caching, CDNs, auto-scaling servers, etc. A bigger install ends up looking like the following, with each piece being able to scale up:

The Evolution

I’ll take a slight detour in our story here to talk about how the web has evolved over the years. HTML was made as a content presentation platform, and while early JavaScript allowed some interactivity, it took a while to really evolve. The big web players were pushing it to be much more.

HTML5/JavaScript is now approaching a real application platform that’s been taking cues from other application platforms like Windows, iOS, Android, etc. On those platforms, if you needed to send data to a server or get some dynamic data, you communicated with an API. If that API was down, these dynamic pieces wouldn’t work, but the rest of your app should still function just fine. This has enabled sites like Facebook to be incredibly complex applications, and it has pushed the technology to a place where we can rethink our stack.

A New Stack

This evolution has led to a new, more modern stack, called JAMStack, i.e. Javascript, APIs, and Markup. The general change in patterns means that what you end up with is much more similar to a combination of the early website pattern and an application pattern.

The Benefits of JAMStack

A JAMStack site builds on a lot of pieces developed along the way, loosely coupling these pieces to allow superior reliability. It takes advantage of CDNs to offer a much more robust caching solution than other stacks. Plus, there’s no server site rendering blocking initial load, so the speed you get is a big improvement.

Extra Pieces

There’s an ecosystem emerging around technologies to support JAMStack sites, such as static site generators, headless CMSes, and serverless APIs. These are loosely coupled as well, so that they don’t break everything if they happen to go down.

• Static Site Generators (SSG)

These allow templating, making pages from data, and other niceties that we’re now used to.

• Headless CMSs

If you need an admin interface for your content, you can still have it. Content is simply now separated from presentation. You administer your content, and your SSG builds the presentation from that content.

• Serverless APIs

Until recently, if you wanted dynamic interaction with an API, you still needed a server running that API. This kept us from really gaining all the benefits of using CDNs — mainly, having no servers to manage. That changed with the addition of serverless/function based offerings. AWS Lambda, Azure Functions, and Google Functions now all support this type of offering, allowing you to pay per execution of your API instead of paying to run the server. It also allows for huge API scalability.

And now, some good links

Smashing Magazine was one of the first larger content sites to roll out a static site. Notice how ridiculously fast the site loads.

Hosting company Netlify was built around the idea of static sites.

Why Static Site Generators Are The Next Big Thing. A post on Smashing Mag by the CEO of Netlify goes into more detail.

What’s our team doing?

The Web team at Mobelux is a React (front-end) and Python/Ruby (back-end) shop, often focused on web apps, so initially it seemed like we could end up in the difficult situation of having to work in different technologies when we were building apps vs. sites. Thankfully, Gatsby is a wonderful static site generator based on React as its Markup (the M in JAM) as well as its JavaScript, and it recently went to 1.0+. Gatsby has let us build static websites in the same technology stack that we use to build web apps.

We were already all in on GraphQL for APIs (which I spoke about at RevolutionConf this year), so using that as our data language in Gatsby fit very nicely with our workflow. We can still write our APIs using Python or Ruby as well, keeping those skills relevant.

Our own proprietary CMS (still in the works) was turned into a headless CMS (with GraphQL API), but more on that soon. For some of these sites, we’ve been using the aforementioned Netlify, and the workflow integration with Github is wonderful.

Taking advantage of those pieces allows us to build fast, reliable, scalable sites using the technology we prefer — and as a bonus, weekends are a lot more carefree, knowing an entire site won’t go down without us. If the return of static sites is the way of the future (even if it was also the way of the past), we’re definitely on board.

The Return of the Static Site was originally published in Mobelux on Medium, where people are continuing the conversation by highlighting and responding to this story.

Within the past month, though, I’ve watched a Swift iOS course taught by Paul Hegarty. I expected the course to cover the basics of Swift without going in depth into the language, but while we began by developing a basic app, we ended with more complex projects.

To start off, Paul constructed a calculator app. The brain of this calculator includes closures to allow binary operations to process thoroughly after the user waits for an answer. Due to the accumulator being a component of multiple methods that changes periodically, mutating functions were essential for this step. Finally, we applied private enumerations and variable to prohibit access from separate classes.

The second application, “FaceIt”, featured an animated face that changes expressions through a segmented control. An appended extension saved the custom names of emotions, and private structures along with static constants were used to make the head shake to a specific degree, which was shared in other methods. Paul continued by setting a method that allowed the facial expressions to change consistently.

Images of life on Earth along with the galaxies of Cassini and Saturn were the focus of the next app, “Cassini.” This app fetches images from the internet via URL links, and we added an activity indicator to inform the user that images were loading. The app requires cellular data if the user is not connected to wifi. For better viewing, users are able to zoom into the picture at a maximum of 100 pixels.

“SmashTag”, the fourth app, uses the Twitter framework to pull tweets. First, we implemented a persistence container to find tweets from keywords when searched. To make it easier for users to be found by acquaintances, we included unique names in the app.

The final application was called “Asteroid,” a space game similar to the 1980s classic, allowing users to control a ship and dodge incoming asteroids. The spaceship can only withstand a few collisions with asteroids until its health is destroyed, at which point its health will replenish within two seconds. We implemented an instantaneous push behavior to start asteroids off in a random direction. The asteroids will consistently be in motion due to a new behavior being addressed, and a switch statement allows the ship's direction to be changed once the user has tapped on it. We used nine images for the explosions, which will be selected randomly.

It’s well known on iTunesU that Paul Hegarty’s Stanford iOS course is valuable, enlighten developers with any range of experience in programming. Calculator app explained how unary and binary operations are used to calculate results using multiple operands, while FaceIt provides the choice to select a variety of facial expressions depending on the user’s mood. With Smashtag, students learn to program a social media application that has over 300 million users. The range of applied skills alone is evidence that Stanford’s iOS 10 course provides knowledge for the basic to complex level of programming.

What I Learned from Paul Hegarty’s Stanford iOS 10 Course was originally published in Mobelux on Medium, where people are continuing the conversation by highlighting and responding to this story.