While I wasn’t born in Baton Rouge, I’ve spent nearly my entire life here. I consider myself a Baton Rouge native, and I love this city. I want nothing more than to see it transcend into a cultural hub where technology, the arts, and people coalesce into a hotspot of passionate innovation.
But I didn’t always feel this way.
When I was about to graduate high school, I sent applications to colleges all over the United States. I wanted nothing more than to leave this place. I wanted to leave and explore and never come back. While I ultimately got into the college I wanted to attend, I didn’t get enough scholarship to foot the bill. Thus, I was relegated to staying home.
At that time, it was an incredible disappointment. I had worked so hard to go away and study at a great school. It felt as though I was being rejected by the world at large. “You’re not good enough to leave,” I imagined the collective world saying to me.
But that’s not what was happening. The world at large wasn’t rejecting me, the state that I call home was simply asking me to stay. It needed me as much as I needed it.
I couldn’t have realized it at the time, but staying in Louisiana would change my life. I have no doubt that if I had left, my path would have been indistinguishable from the path that I’m on now. Because, in reality, I was offered so many opportunities here that I wouldn’t have had otherwise. Being here opened me up to the kind of thinking that allowed me to start my own business, and the economic climate here has allowed me to succeed, create jobs, and make awesome apps.
Now that I’m here, I’m all in. I want to do everything to help push us forward, to turn this city into what I know it can be. It’s a block of marble, as Jeff Roedel so eloquently put it in 225.
There’s this great story of Michelangelo. A young prince wandered upon him as he was staring at a mammoth, unworked 18-foot block of marble. The prince asked the obvious: “What are you doing?” Michelangelo replied, “I’m working.” He did that every day without relent. Three years later, that piece of marble was the statue of David.
Baton Rouge, and Louisiana in general, is that block of marble. In place of Michelangelo, we have brilliant entrepreneurs who are working non-stop to create a better city. Casey Phillips, a friend of mine, is one of those people. A distinct piece of what Baton Rouge will look like has already started with his help in the form of the Baton Rouge Walls Project.
The whole goal of the project is to use the many blank walls of downtown Baton Rouge as giant canvases that local artists can turn into something beautiful. There’s so much amazing surrounding this project, that it’s hard not to be excited about it.
Creating a more beautiful downtown is just step one. And you can be a part of it.
Join me in turning this idea into reality. Back this project on Kickstarter. Any amount is significant to help turn downtown Baton Rouge into a canvas.
The issue of whether to build a mobile-optimized web site versus a truly native mobile app is a widely contested issue. From conference seminars, to popular blog posts, to internal debate amongst our team, this is one of the most crucial debates of our time.
We’ve long been on the side of native mobile apps. We think that in the future HTML5 will enable mobile sites to be just as good as mobile apps in most cases, but for now mobile apps are superior in many ways. Despite being much faster (which is one of the most important features an app can have), native apps allow for greater interaction and more granular control over aspects of the app.
We’re constantly reevaluating our position to make sure that we’re recommending the best option to our clients. We’ve been really impressed with all of the mobile frameworks coming out and responsive design is something we’re becoming increasingly invested in. But for now, native apps are the way to go.
Jakob Nielsen, an interaction and usability expert, posted on his blog recently about this debate. His research in testing this topic comes to conclusions that are congruent to ours: build native apps (in most cases) over mobile web sites — for now, at least.
We disagree with Nielsen that this is going to change. We think that for the near future native apps will remain the front-runner because of the raw power that native code provides. Of course, future predictions aren’t meaningful now, and we’re keeping an eye on how the technology develops. As Nielsen says, you don’t really need to know why the winner is best, just that it is.
The question of whether to build a native app or a mobile web site is an important one. If you have any questions, we’d love to site down with you and talk about the merits of each. We’ll explore your concept together and decide what’s the most appropriate for your project. Say email@example.com to get started today.
In the future, we’ll talk about some common scenarios and which strategy we think is best. In the meantime, checkout Nielsen’s blog here.
The Greater Baton Rouge Business Report featured me in their latest print issue in the Entrepreneur Section. It’s a great article talking about our founding story, where we are today and where we’re going in the future. If you’re interested in how we got here, check it out! It’s also available online here.
Today we’re pleased to announce the launch of Heartwaves.org, a social hub for parents with children suffering from a congenital heart defect.
Heartwaves is the dream of founder Jared Broussard, a Baton Rouge native who has a son with a congenital heart defect. I first met Jared last April when he presented his idea to me. I knew right away that it was something we wanted to be a part of.
We didn’t start this company just to create apps for big firms. We created this company to help people who had passion and vision. Jared fits this perfectly.
We’re excited to be a part of this with Jared and look forward to helping families connect all across the nation.
I want to take a moment to thank the Heartwaves design partner Andy Gutowski of Object 9 and Christian Bankester who was the senior developer on Heartwaves.
For more information, read the article in the Business Report. You can sign up for an account or browse the site here.
I was honored to be invited back to LSMSA, the high school that Evan and I (and a majority of our team) graduated from, to speak. I talked about my college and career path and also some mistakes I’ve made and lessons I’ve learned. The talk is titled “Ten Things I Wish I Had Known”. You can find the slides on SpeakerDeck.
I remember the first time I came in contact with a device Steve invented, imagined, dreamed. I was nine years old. My father had just brought home one of the new bondi blue iMacs.
“Where’s the rest of it,” I said inquisitively. At this point in my life, my father had already introduced me to computers. I knew about their construction, design and components. I had never seen anything like this — none of us had.
“It all fits inside. It’s all there,” he told me.
“How?” I was beyond confused.
My father was right. It was magic. Not because it was physically impossible, that it was some sort of allusion. It merely seemed magical. When you bend the idea of what is possible, you get magical. That’s what Steve was known for.
As I grew up, I continued my exploration into technology. I was always fiddling, tinkering, programming. This was largely on Windows computers. But at a certain point that changed.
I remember seeing a small blurb somewhere about Tiger, a new OS coming from Apple. I hadn’t seen anything Apple in years, so I read more. I was intrigued.
By time the keynote came around, I was hooked. Apple was amazing. I had to see this thing.
I was 16. I was waiting in the car as my mom and sister ran into an appointment. I had been able to grab a wifi signal in the car, so I insisted on staying put to watch what unfolded.
It was magical.
I didn’t know it at the time, but there, in my mom’s minivan, with an aging Dell and a stolen wifi signal, a man whom I’d never meet and whom never’d know my name, profoundly changed my life.
Three years later, I’d be employed by Steve. I was a campus representative at LSU for two years. It was an amazing experience and I loved every minute of it.
It gave me the chance to tell people about the products that I love, built by the company I love. I got to share my passion with my peers. I showed them what it feels like to be inspired by a computer, what it feels like to feel joy when using a phone, what the magic of the iPad feels like.
I thank Steve immensely for that opportunity. It was, by far, my favorite employment. The only thing that could get me to leave was to start my own company. And I somehow feel that he would’ve encouraged me to do so.
His devices, his company — it’s all truly magical. What he’s given us, what he’s set in motion — it’ll last for generations to come. I rest easy knowing I’ll be using — creating — with devices that were built with people like me in mind for years to come.
But Steve’s true legacy to me — the way he truly impacted my life — isn’t what he made. It’s what he taught me.
He taught me what design meant. He taught me that it’s important and that it’s not just what it looks like, it’s also what it feels like. He taught me to sweat the small stuff. He taught me that it’s OK to be a perfectionist. He showed me how to make insanely great products and he showed me how to sell them.
He also taught me how to build a company. He taught me how to manage people. He taught me how to instill a burning passion. He taught me that the single most important thing is the people who work for you.
He taught me to live my life, to not be trapped by other people’s dogma. He taught me how to shrug off the weight and embarrassment of failure. He taught me how to follow my heart. He taught me that doing what I love is the single most important thing in life.
Five years later, I’m an entrepreneur. I’m doing what I love. I’m building things for people. I’m creating. And I credit Steve with showing me how.
Steve inspired. He left a legacy. He did and gave so much in his short time with us. We can only dream of giving back in the magnitude that he did.
But that’s just it. If anything, we should know that that’s not what matters. Doing what you love, being kind, doing good — those are the important things.
Having unwavering courage in the face of certain failure. Having the audacity to do what’s right. Having the passion to do what you love. That’s what he left us with. That’s what I’m most inspired by.
Steve, I’m crazy enough to change the world. I’m crazy enough to think that I can leave a dent in the universe. I’ll never grow up. I’ll always stay hungry and foolish. I’ll always think different. And I’m thankful that you were there to show me how.
There are many people I respect. There are few I consider heroes. There is only one Steve Jobs.
Steve, may your legacy continue forever to inspire people to imagine, create and believe in the impossible.
With love and humility and the courage to keep innovating,
We have a Rails app that essentially acts as an API for an iOS app. It provides JSON endpoints to pull some resources. The iOS app only reads data, so the only verb used is GET. There are dedicated controllers just for the API actions — the admin backend is handled through separate controllers.
I was making some updates to admin backend yesterday and I noticed that the API controllers needed some attention. They were standard controllers, so they were inheriting from ActionController::Base, which includes a lot of stuff we just didn’t need. I ran a quick test with Apache benchmark and the median response time over 1,000 requests was roughly 630ms. Wow! I can do better than that.
Since Rails 3.0, we’ve had the ability to instead inherit from ActionController::Metal. It’s bare metal, if you will, and includes the basics. You have to add in the modules you need on top, so you really get to fine tune what the controller does. I had to dig around in the Rails source and figure out the modules I needed, but in the end we saw an amazing 50% performance increase — the media response was down to just 325ms. It’s really noticeable on the iOS side, too.
Here’s an example controller:
class ArticlesController < ActionController::Metal
@articles = Article.order("published desc").limit(25)
@article = Article.find(params[:id])
One of the axioms of our mission statement is to be charitable. This community has done so much for us — it’s given us a home, fostered our growth, and provides a platform for expansion — so we want to do what little we can to help give back.
The thing we do well (somewhat obviously) is web and mobile, so when charities approach us to help out we try to find innovative web and mobile solutions to help them get their message out across wider audiences.
This year the Capital Area United Way approached us about building an app for their Jambalaya Jam event. It’s held every fall and it’s one of their biggest fundraisers. An app, they reasoned, would increase interaction and, thus, funds. We liked it.
The event is still a few weeks away, but you can get the app now. Search “Jambalaya Jam” in the app store or click here.
Download the app and join us October 6 downtown for an amazing night filled with good food, plenty to drink and awesome bands as we raise money for an organization that helps the community. You can buy tickets here.
We’re honored to be a part of this special event. If you’re there, be sure to say hello!
Update: The original post had October 8 written as the event date. The correct date is October 6. The post has been updated to reflect this. Sorry!
I was recently at lunch showing off a project to one of our clients. I don’t often think about internet access before I go anywhere — these days I just assume I’ll always have internet. Unfortunately, however, this particular restaurant didn’t have public WiFi. Well, that shouldn’t be a problem — I’m showing the app locally anyway.
I got to the restaurant, opened my laptop, tried to access app.dev and bam — I got the sad “no internet connection” error page. I thought for a second. I could boot up the server on my machine; localhost will be available. But wait, if localhost is available, shouldn’t my .dev domains? They’re not real domains! But your computer thinks they are. That’s why it tries to connect to the internet. But with one simple line in your hosts file (/etc/hosts on a Mac) you can easily convince your computer that they’re not. Just add the following after the localhost declarations:
That’ll make sure that your computer routes all requests for app.dev to your local machine. Somewhat inconveniently, the hosts file doesn’t accept wildcard characters, so you’ll have to add entries for each of your apps.
Being Awesome, One Build at a Time from NewAperio on Vimeo.
We were invited to speak at LSU CCT's iOS Bootcamp. Hear our talk on our company, the development process, and how to be awesome.