Blah, blah, blog.


We created a blog at for us developers here at mysterious trousers to share with each other interesting things we find as we rock iOS and Rails development. If you’re interested in those things, you are more than welcome to follow along. You can also follow the mysterious trousers developer team twitter account!/mysteriousdevs . All blog posts will be posted to that twitter stream, so thats a good way to be aware of new posts.

2 years ago adam

First there were websites…

…Then there were web APPS. Now is the dawn of the browser app.

What is a browser app? How is it different than a web app? And, how is it done?

Glad you asked.

Web apps were the natural progression to web sites. Web sites were just brochures for a while, but soon we wanted websites to do stuff.

A web app is just a glorified website. You navigate from page to page, downloading the whole thing each time. Looking back, it seems kind of ridiculous to download an application you’re using over and over with every click of your mouse. Granted, browsers will cache the heavy assets, but the browser has to reinterpret all “boot up” code in your app every time the user does something.

Then came AJAX and web sockets. Then came Ruby on Rails. Then came jQuery and Backbone.js. Then came Sprockets and CoffeeScript. These were all improvements leading toward a new kind of web application, the browser app. (Don’t confuse this with browser plugin or Chrome’s browser apps).

Browser apps act more like native apps than web apps. A browser app is a package of assets (javascripts, stylesheets, images) and ONE web page. Unlike a web app where you are downloading the entire application (javascripts, stylesheets, html, images) with every single action, a browser app is downloaded once, and then ONLY communicates with the server to transmit DATA. I’m trying to make the distinction clear between the application (the assets) and the data (the user specific information).

When you downloaded Google Earth (don’t tell me you didn’t), you downloaded a package of assets, then you ran it and it sent and received short snippets of text to the server. Sounds pretty similar to a browser app!

Here at Mysterious Trousers, we only build browser apps. With every browser app, we essential create two applications, the server and the client. We start with the server. We design the API and we write unit tests that exercise every single possible way that you could interact with our server from the outside. Then, we eat our own dog food and use that API to build our client application.

The server application is written in Ruby on Rails and is strictly RESTful. We get out a piece of paper and write down all the things we want our application to do and then we design an API with all the RESTful routes we’ll need. Every single route returns JSON except for ONE, the root url of the application, which returns to the browser the package of assets that make up the client application. The browser starts running the client app and boom, for all intents and purposes, you just opened a native app.

This is awesome because: - You don’t have to write the application and then a “public” API. What you designed for your own app is what you release to other developers…and its released the when your app is released…it is your app. - It’s way more secure because you’ve simplified your whole product into two apps. All you have to worry about is your server’s API. You can only get at your servers data through the API and if you write tons of really robust unit tests that test every single possible way to interact with the API, no one is gonna be messing with your server in a way you don’t expect. - Your server only has to parse short snippets of JSON and then return short snippets of JSON, drastically reducing the load on your server.

The Server: - Written with Ruby on Rails, the server responds to all our client’s API requests in JSON and returns the compiled and compressed client application. - JSON takes about half the text that XML needs to represent the same thing. XML can suck a lemon. - Rails 3.1 has the asset pipeline that compresses all our client code for quick downloading a just a few requests. - Run on Heroku, Cedar Stack.

The Client: - CoffeeScript to write really clean and easy to read javascript (not to mention valid). - Backbone.js takes care of all of the generic stuff and lets us focus on writing the code specific to our app. - The rails-backbone gem to help us quickly layout scaffolding for our resources.

Also: - Pusher so that the server can push information to the client without having to poll the client every few seconds. - Airbrake so that we can get detailed error reports that are grouped together and easy to manage.

Check out our latest app, to see a true, modern, browser app.

2 years ago adam

TinkerLearn Feedback

So we have about 150+ people trying out TinkerLearn we’re getting TONS of great feedback. Just a taste:

"This part was really fun!!" "Very helpful!"

"Told me what I needed to know!"

"Great tutorial for beginners!"

"I think you have a great idea here! "

"Very helpful…life is good. :@)"

"Brilliant, delightful, and communicates instructive information. Bravo!"

We REALLY want everyone to give this a try and tell us what you think. We’re refining it to perfection at a steady clip, so if you stick with us, we promise we’ll soon have something that really will help any level beginner learn to make an iPhone app. I know from talking to enough people that pretty much everyone wishes they could make their own iPhone app, so get to it: No spam, just an e-mail invite once you submit your e-mail address.

2 years ago adam

TinkerLearn Update

This is an e-mail from Parker to all of us. I’m posting it because it says a lot about what we are trying to do with TinkerLearn. Again, if you’d like to be a beta tester (and we’ll pretty much accept everyone that signs up) please go here:

The email:

been thinking for the past little while about strategies for TinkerLearn
and, having pushed out the beta, I’d like to start throwing ideas

I’ve been considering the “focus” of TinkerLearn. I feel that tutorials have the following weaknesses which TinkerLearn addresses:

  • They are “learn iOS in 20 minutes!” usually, and are therefore too narrow in scope and not practical in building useful apps with real value
    • TinkerLearn projects, to begin with in the free ones, are fairly trivial to teach really basic concepts. But all of our paid apps should be solid, useful apps that reflect building something actually downloaded and valued by users
  • Tutorials become outdated easily. I’m always checking the date a blog/tutorial was published and get worried if it’s over a year or so. Websites often boast stuff like “300 hours of tutorials!”, but as soon as the new iOS versions comes out, it’s not easy to update 300 hours of video to accommodate new features
    • Updating a project to use new iOS features is much easier that updating an entire library or tutorials and videos.
  • Tutorials don’t usually adapt to their user’s needs, they are what they are. Users leave comments, but that form of feedback doesn’t seem too effective
    • TinkerLearn, in every aspect, is user driven. The US Constitution is called a “living document”, created and changed by the people. I like to refer to TinkerLearn as a “living website” with “living projects”. Our glossaries, projects, and everything else accepts targeted feedback. Our system of feedback is much more granular than “leave a comment about this entire 5-page tutorial” and will allow us to really target problems in our projects and fix them.

I have the following ideas that will help us to get our name out and focus more on these principles:

  • Recently, when thinking about new app ideas, I’ve been thinking like this: “We need to teach about table views. How can I come up with a concept that revolves around table views?”. I think this is the wrong way to go about it. Instead, I think we should approach it the opposite way: “What are really cool app ideas? What concepts can we teach from this cool app?” This will allow us to focus on teaching pertinent concepts related to real-word apps instead of trivial tutorials. Instead of my original approach, a better one would be that after we brainstorm dozens of great app ideas, we pick out the best one of those that demonstrates table views.
  • We’ve discussed getting our Twitter following involved. A good way to do this might be to ask what apps they would like built. People are ALWAYS giving us developers “advice” on what apps to build. This is their chance to suggest good ideas, have them built, AND get the source code for it.
  • We should have some way of collecting and brainstorming app ideas within MT. We could even go so far as to build app suggestions into the website for the users. I think reinforcing to the users as much as possible that they are being heard and making a difference will make them more invested in using our services. Users could vote on what projects they want to see built. However, this might take some thought to make sure it was done effectively. An idea to consider all the same.

Ideas that Adam had that I think are great:
  • Have projects dedicated to teaching just the basics of programming. Loops, flow control, variables, etc. Cutting out the amount of “this is a variable. A variable is 85” in the later projects will really help the tutorials have more focus instead of trying to explain everything every time it comes up. These projects could be in Ruby or in Obj-C. Ruby’s syntax is more friendly to get into, but it might confuse them once they get into iOS. Maybe a project where all there is is an App Delegate with a bunch of control/basic stuff in it. Maybe we draw some shapes to the screen and the user, by changing loop counters and the conditionals in if statements, can affect what is displayed. We won’t have to explain any of the drawing to screen stuff, it’ll just be straight up procedural code inside applicationDidFinishLaunching:withOptions:. Thoughts?

As far as where to go from here, there’s a few different things:

  • Finish Core Cirriculum
    • I’m thinking that Level 3 should be a data structures/Obj-C project that drives home stuff like creating your own classes, writing your own methods for those classes, using NSArray/NSDictionary/etc, and just in general gets them comfortable writing Obj-C code. LOTS of good TINKER and CHALLENGE sections that give them lots to do on their own. In levels 1 and 2, all our methods and variables are created by Interface Builder for the most part, so I think this is necessary.
    • Level 4 I’m leaning toward a Table View app of some sort. This will really try to drive home the purpose of delegates with UITableViewDelegate and UITableViewDataSource, as well as demonstrate how UITableViews are used all over the place.
    • Level 5 should be a really serious app that pulls together everything from the previous levels into a fairly complex app.
    • Again, I think we should approach all of these by first making a list of cool app ideas, then afterward come back and ask ourselves “Which one of these will help teach data structures effectively? Which one will help teach table views effectively? Which one will be a nice mixture of everything to round out the core curriculum?”
  • Update current projects to reflect user feedback
    • Some feedback has started coming in. I’ve invited roughly 25 beta testers, and it doesn’t look like there’s any problems so far. I’m going to add the rest either later tonight or tomorrow morning (once the current 25 have had a chance to come home from work and really test it out, only 14 people have actually logged into their account so far)
    • I’m thinking we’ll split up the projects between Joe and I for now (Joe will look at feedback for and make changes for Project 1, I’ll do project 2).
  • Review new ideas
    • Joe had some ideas for the website that he put into Kickoff, such as a “vocabulary” system similar to the glossary. I was thinking that we should also start tagging projects, once we get more, so people can see which projects emphasize in what (this will probably not be too necessary until we get a good number of app in there)

Anyway, I’m sure there’s more that I’m not thinking of at the moment. Let me know your thoughts (be sure to hit reply all). I’ll start synthesizing our thoughts in a note on Kickoff,


2 years ago adam

Calvetica 4.3 Beta 1

We just sent our first beta of Calvetica 4.3 to our testers. That means we’re close. It should just be another week or two before we are ready to submit it to the app store. Thanks everyone for waiting.

This version will not have many new features. It’s been a huge struggle to get it working great on iOS 5 and we’ve just been trying to make it faster, more stable, and fixing bugs.

We’re looking forward to 4.4 to be a great release.

2 years ago adam


Ok folks, our boy Parker is working on our “learning iOS” product and we’ve got a very unique approach, which we believe is our secret sauce, so we’re not going to share what our approach is just yet, but soon we are going to want “beta testers” that vary in programming literacy to try it out for us and offer feedback. We want to make sure that this product can help everyone from any skill level to stay motivated and learn iOS.

Now, this is just a heads up, please don’t slam us with tweets and emails about wanting to be a beta tester. I’ll set up an apply form in a bit that will help us collect interested persons info. We got a ton of great feedback that a LOT of our followers are interested in learning how to make iOS apps. And, judging by the very diverse group that is our twitter followers, we estimate that a lot of people all over the world want to learn and are going to find our approach to be the only one they can swallow.

In this tough economy, a lot of people could benefit from an extra couple hundred bucks a month from selling a little iPhone app they wrote in their spare time.

Oh, and we’re calling it “TinkerLearn.” Let us know if this conflicts with anything, we know an effort by a similar name was offering us advice when i mentioned this earlier.

2 years ago adam

Learning iOS

We’re studying how to best teach people how to program and do iOS development. How many of our followers know iOS dev? How did you learn it? What do you think is the best way to learn it? How many WANT to learn it? How many want to learn it, have tried, got frustrated and decided it probably wasn’t worth it? How many haven’t even thought about it, but if an interesting way to learn it was presented, you’d consider it?

2 years ago adam

Calvetica: Next Big Feature

If you would like to see templates in the next version of Calvetica, speak up on twitter.

Templates are kind of like having a list of events you can copy and change to create new events from.

We’ve had a few people beg for them, but we’re just not sure what percentage of our users would use them ever. We don’t want to add things that 90% of our users NEVER use.

2 years ago adam

Speaking of Dialvetica

Can anyone explain to us why Dialvetica doesn’t do better than it does? It is hands-down the most beloved and used app here at mysterious trousers and we seriously can’t figure out why everyone with an iPhone hasn’t bought it. It solves a REAL problem, initiating contacts on the iPhone without it sucks. With it, it’s a frickin’ breeze. Is it our marketing? The color? Seriously, some of you business geniuses, that can testify of it’s awesomeness, can offer us some good advice I’m sure.

2 years ago adam

Dialvetica…even faster

I just changed Dialvetica to almost entirely refresh the contacts list when the app goes to the background. This way, when you bring the app to the front again, most likely cause you want to contact someone, the spinner will go away faster because half of what was being processed before, when the app became active, is now being processed when the app goes inactive.

Submitting Dialvetica 2.3 now. You should get it in a few days.


© 2012 Mysterious Trousers, LLC. Fantasticness does exist and it’s tied up in our basement.