Our Thoughts

Host your site on CloudMine (and deploy it with a push)

derekmansen — Tue, 11 Dec 2012 10:58:34 -0500

We’ve been polishing this feature for a while now, and we’re pleased to officially announce it. You can now use CloudMine to host your HTML5 / JavaScript powered apps. We’ve streamlined the deploy process: you can either drag-and-drop your site’s assets into the Dashboard, or use a git push-based deploy system.

How does it work?

Sign in to your CloudMine account and navigate to your Dashboard. Follow the instructions to create a new site. You’ll be given the option to deploy your site via a zip file of assets, or via git. If you’ve ever used Heroku, you already know how your site deploys will work - just add the CloudMine remote, and push to it when you make changes.

Features

We’ll provide you with a generated hostname (efficient-border-30.cloudmineapp.com being an example). However, it’s easy to use your own domain: just CNAME your domain to cloudmineapp.com and write it in the Additional Host Names field - we take care of the rest.

We also provide SSL support automatically - just visit your host with https instead of http (see https://pennapps.cloudmineapp.com for an example).

Teaming up with Singly for Social Superpowers

marcweil — Mon, 12 Nov 2012 10:30:00 -0500

(Skip down to the video if you don’t feel like reading!)

There’s a new hip or useful breakout app coming out every few weeks.

It’s already less-than-easy to integrate with prevalent and mature APIs like Facebook, Twitter and Instagram (who likes dealing with OAuth themselves, anyway?). So who really wants to keep tabs on, much less do the work to integrate with, these and other more niche channels for identity, data access, synching, sharing and a whole host of the messy data work that goes with it?

Enter Singly - the fabric that connects apps together, empowering the rapidly expanding, new class of mobile developers. Singly’s service bridges an app user’s data and friends from one app to another in more powerful ways while saving developers time and energy replicating common patterns and maintenance fixes. Whether you want users to login with their GitHub, Twitter, Flickr, Google or any other myriad of accounts — Singly rounds up all APIs into one, providing developers with a unique and useful service.

“What does this mean for me?” you ask. Good question!

Prior to now, in order to use our account management and privacy features you had to prompt the user for an email address and password. Our partnership and integration with Singly allows you to create user accounts using any of the major social networks. This makes it trivial to have that “Login With Facebook” or “Login with Twitter” button, but with many of the social networks Singly supports: Facebook, Foursquare, LinkedIn, Twitter, Withings, Dropbox, FitBit, GitHub, Wordpress, Instagram, Meetup.com, Tumblr, and Yammer (say that all in one breath!). As Singly integrates with more networks (which they do at a blazingly fast speed) we will support them as well.

Beyond auth and login, Singly also gives you fast, structured user data from those networks (like photos, friends, checkins etc). And best of all you get access to all of this through your CloudMine account using our existing APIs! Singly has been completely integrated into the CloudMine platform, OAuth and all.

All this not only makes it possible to authenticate using a popular social network, but it also makes it even easier to engage with users’ connections on these networks. All that’s left to do is bask in your success and focus on making an awesome app!

Read about how to quickly implement social logins in your app in our docs (REST, JavaScript, Android). iOS developers: never fear, native social integration will be coming to you soon.

(CloudMine + Singly Partnership Announcement from CloudMine on Vimeo)

And as always, please feel free to reach out to us with any questions at team@cloudmine.me, via Twitter @cloudmine, or by using the comments section below.

Design Breakdown: UX, UI and Why — The New Dashboard

unleadedthought — Wed, 31 Oct 2012 14:23:57 -0400

Over the past couple of weeks, the CloudMine team has made a number of leaps forward with our technology. We’ve integrated git for hosted sites, we’ve added a new level of API access for use in development mode, and we have a super secret social offering that is right around the corner.

As we increase the number of service offerings for our clients, we also increase the number of interaction points in our dashboard. And this directly correlates to increased complexity of user flow — if you know anything about me, then you know I strive for simplicity & cleanliness.

Why Change?

We could easily evolve our dashboard into a command interface, but internally, we want to flirt on the side of direct manipulation. By doing this, we don’t limit our users control or function, while also decreasing the possibility of someone getting lost in control complexity — this line is thin.

So, our masterful front end engineer, Steven, and I took a long hard look at how people interact with our dashboard — We performed a task breakdown analysis and spec’d out user goals. The following is a comparison of what we changed in our dashboard, accompanied with the always comforting reason of ‘Why?’

Change Breakdown

As you can see with our old styling, we relied heavily on the left navigation pane. Segmenting Apps, Hosted Sites and Account. There are two problems with this setup, one is the dynamic application tool (highlighted to the left). This tool is an issue when you click on ‘object browser’ or ‘file browser,’ — two additional tools appear, pushing the navigation down. Moving navigational elements is not standard convention and hinders user autonomy, navigational elements should always be preserved throughout an environment.

Which brings me to a second issue. The visual clutter we began to amass with our navigation styles. I say this because there are three hierarchical categories in our side nav, Apps, Hosted Sites, & Account. Everything below these items is a child to the respective category. But our visual weighting does not delineate this relationship, rather it suggests the opposite.

So, we migrated the styles defined in our Documentation page to maintain visual consistency, and to clarify the parent child relationship. This visual language also affords a lessened visual stress in navigating the dashboard, increases user efficiency and ease of navigation — Clean

In addition, we moved the dynamic tool panels below the navigation. We now have much more vertical pixel space — eye fatigue is lessened by having a smaller area of scannable information, and navigational elements adhere to the consistency
and standards of navigation design.

What’s that you ask, where’d your hosted sites and account settings go?!

Don’t worry, we kept all that stuff around. In fact, now you have a sleek new tabbed interface. The tabs encapsulate user work spaces within the dashboard — Applications, Hosted Sites and Account. People don’t tend to work on more than one of these categories during a given time, and so it makes more sense for an individuals mental model to separate this workflow. Hosted sites and Account details are not cluttering your interaction points or deterring your focus from the more important navigational elements.

Testing New Methods of Interaction

Some things you need to prototype and test in the field, gain valuable insight and iterate. And so we’re testing a new method of adding and selecting apps, or hosted sites — for that matter — as seen in the screenshots below. Go interact with them. Let us know your thoughts.

New Application Selection Method:

Old Application Selection Method:

There's Plenty of Sleep in Hustle

derekmansen — Mon, 22 Oct 2012 08:30:12 -0400

Everyone who knows us has probably seen our “There’s No Sleep in Hustle” t-shirts by now. This began with something the great Rob Spector (https://twitter.com/dn0t) said at a hackathon, and has since entered the lexicon as the CloudMine Thing We Say. We love Rob, and we love the shirts, but they are intended to be a bit tongue-in-cheek—and we’d like to clear the air about how our working lives actually are.

Overwork is bad.

This is a fact. Anybody who tries to tell you otherwise can be refuted by a myraid of studies (http://www.igda.org/why-crunch-modes-doesnt-work-six-lessons) (http://www.good.is/posts/don-t-fall-asleep-at-the-wheel-successful-entrepreneurs-have-lives/) (probably more) that show that going into “crunch mode” is the single most expensive way to get things done, going all the way back to Henry Ford and his factories. Here’s a great quote from the above essay:

When Henry Ford famously adopted a 40-hour workweek in 1926, he was bitterly criticized by members of the National Association of Manufacturers. But his experiments, which he’d been conducting for at least 12 years, showed him clearly that cutting the workday from ten hours to eight hours — and the workweek from six days to five days — increased total worker output and reduced production cost. Ford spoke glowingly of the social benefits of a shorter workweek, couched firmly in terms of how increased time for consumption was good for everyone. But the core of his argument was that reduced shift length meant more output.

This bears repeating: reducing shift length meant more output. Often, the reasons cited for keeping the number of hours worked at a reasonable level are things like employee morale, health, etc. These are all important, and valid. But, I’m sure there are plenty of startup founders / managers who, while they don’t explicitly encourage their employees to work extra hours, are nonetheless pleased when their employees go the “extra mile” and crank away in crunch mode of their own volition.

This is a mistake. The correct response to this is to force your employees to go home. Yes, force. This is good for the employees and good for the business, and there’s no denying that.

Fight the Temptation!

Now, I’m sure there are plenty of people out there right now who are saying: “Well Derek, I enjoy working the long hours! Work is my passion, and I want to do it all the time and there’s nothing wrong with that.” I say there is: when you overwork yourself, you’re doing a disservice to everyone you work with. Your mind can’t work at full capacity and your output gets sloppy.

I can say this from personal experience: when I was implementing the hosted sites feature for CloudMine, I was working twelve hours a day to get it done by a deadline. This was almost entirely self-imposed, by the way: I was never told I had to work these hours! And, of course, I thought I enjoyed it! I was a hero! People will sing my praises from above when I get this thing done!

Okay, so that’s not really what happened. What happened was:

I was miserable, balancing out my unhappiness with self-medicative drinking.
My relationships with the founders (whom I consider very close friends) started to deteriorate because I resented them and blamed them for what I was putting myself through.
Last but not least: the code I wrote was terrible. (It has since been re-architected.)

I went on vacation shortly after the feature was completed. I turned off my phone and disconnected completely for a full week. It took me about two days to reach a relaxed state of mind after the stress I had been under.

When I returned, one of my managers told me, flat-out: “Listen, I totally understand why, but that code from those twelve-hour days was the worst you’ve ever written.”

This was a revelation. I replied, “Great! I won’t do that again.” And I try not to. Because there’s no point. Now, I go to bed early, wake up at 7 am, and produce my best work. I’m proud of it, and I don’t have to kill myself to do it. Not only that, but my extracurricular hobbies have blossomed: I’ve been writing lots of songs that I’m proud of, and improving my writing in leaps and bounds. I directly attribute this to improving my work-life balance.

Don’t chase the dragon. Take a break - you’ll solve the problem in the shower later, instead of after ten cups of coffee at 2 am, and you’ll feel better for it.

The Global Backend as a Service

unleadedthought — Thu, 04 Oct 2012 12:38:00 -0400

A Hunch

A few weeks ago we had this hunch. Our hypothesis was that developers from around the world are building applications on the CloudMine platform. Being so intrigued with data, we hit up one of our databases and pulled down a list of IP addresses of people who signed up. We then mapped this dataset against a public record of IP address locations to aggregate their appropriate country of origin. Next, I went to work crunching the numbers and allocating the visual elements to create a heat map of where our users signed up from.

Understanding and Influence

The interesting nugget of information we garnered from this research is that 48% of all accounts are from outside the United States. That’s almost half of our user base! We were not expecting results like this, and quite frankly, we were pretty stoked that we have such a varied base of developers on CloudMine.

Pieces of information like this help inform our internal design team to focus our product enhancements and UI requirements. Empathizing with our users means understanding that English may not be their primary language. So, we design our dashboard and site interactions to easily afford new users a strong mental model of how to navigate and use our product — across all language barriers.

Reasoning

Looking through Google Analytics points us to how we have been able to spread so far and wide. You see, we’re a global sponsor of Startup Weekend — you can see our logo below the fold of their landing page ; ] — Because our company was founded out of a Startup weekend here in Philly, we enjoy giving back and helping out future startup leaders.

We’ve attended somewhere around 20 startup weekends and had 4 representatives floating around Startup Weekend Philly just this past weekend. We help coach the teams for success while also judging their technical involvement and inquiry. If one of the teams is set on developing an application, well, then we’re there to help them get that done, and to build that app as quickly, successfully and professionally as possible, too.

Reflection

Sponsoring Startup Weekend has been great on many levels. We’ve networked with some amazing individuals from all over the United States and have been able to reach out across the globe to countries like Japan, Germany, Brazil, and even Iceland to get developers all over the world using and investigating CloudMine.

If you happen to be one of those developers, near or far, feel free to drop a line, tell us your experiences. If it wasn’t from Startup Weekend, how’d you come across our platform? Or, if you’d like to become more involved and happen to be in Philadelphia, swing into our office at Venturef0rth — I’ll buy you lunch and we can chat about CloudMine. And life.

What We've Learned By Evolving Our Documentation

derekmansen — Wed, 26 Sep 2012 13:03:00 -0400

With the recent release of our brand-new documentation, we’d like to elaborate on how the docs and our process have evolved through the product’s lifetime.

In the beginning

The first version of CloudMine was a REST API. We documented all of the endpoints and provided guidelines on how to use them. This was sufficient at first, before we had written any native libraries.

The navigation at the time was flat list of operations (usually corresponding with a single HTTP endpoint). This was feasible at the time, because there weren’t many features yet, but we knew this was going to change soon.

Adding libraries

As the libraries were being developed, we had to address the issue of documenting them. After all, a library without documentation is about as useful as no library at all.

Being the disciplined developers we are, we decided that each library should have API documentation in-code (with HTML generated by Javadoc, or Doxygen) before release. This gave us something to work with. We also wrote Getting Started guides for each, so that developers had something besides a large list of functions with minimal organization.

Organization

As the number of features grew, we noticed that the navigation was starting to get cluttered with everything that we had added. So, we sat down and divided out individual operations into their most logical divisions of high-level features.

Feedback

At this point, we had extensively documented the REST API, and had detailed API documentation for the iOS, Android, PhoneGap and JavaScript libraries. Through our own internal use and outside feedback, we quickly learned that API docs are necessary but not sufficient for a platform like ours. Problems with them included:

API docs are difficult to navigate.

This type of documentation is like reading the docs for a programming language that lumps all functions into a global namespace. There’s no “start here” - it’s tough to get an idea where to begin unless you already know where you’re going.

Can’t develop best practices.

API docs are a fairly thin layer of abstraction over the code. You can’t really see the big picture when you’re looking at detailed type information for everything.

Important concepts are omitted.

Big-picture concepts and overall system architecture aren’t referred to at all. This is another side effect of the docs being “too close to the code”, so to speak.

How do we fill in the gap?

Once we identified problems with the current docs, it was time to come up with a plan to fix them. We ended up taking a three-tiered approach.

Sample apps

Full, working sample apps provide a huge amount of value. Putting together the structure and initial version of an app is a daunting task, and having a new service API to learn on top doesn’t help the situation!

Sample applications like Todoly or DeviceTracker for each of our supported platforms help ease developers into using CloudMine. This frees you from needing to think about things like “where should I put this initialization code?”, and gives you a higher-level view of how your application might be structured.

Examples, examples, examples

Previously, our docs were lacking in the examples department. Our new goal was fairly ambitious: working, copy-pastable examples for every function CloudMine supports, for every library. It took quite a bit of effort, but we now have that for all of our native libraries.

Create a higher-level documentation flow

We know developers, and we know that when you can’t find the information you want (especially from a 3rd party), your opinion of that documentation, and the product, quickly deteriorates. We wanted users to have a clear flow from the most general to the most specific docs. That flow looks like this:

“Getting Started” and tutorial sections for libraries.
Extensive high-level examples for libraries.
API documentation that captures lower-level implementation details, just above the code.
The code itself. Code is a form of documentation - one of the best there is. All of our libraries are open source.

We want motivated developers to be able to get all the information they need without ever having to contact us. It’s important to keep your users in the loop, especially when they are relying on you for a critical service.

Of course, we still encourage developers to contact us if they need to - but the point is, they shouldn’t be forced to!

Next Steps

We’re very proud of the current state of our documentation. However, we see no reason to stay complacent with what we have, and have already been thinking about how we can make our docs even better. Here are a couple things we plan on rolling out in the near future.

Interactive documentation

All of the code examples are copy-pastable - as long as you modify things like your app ID and API key. We’d like to populate those automatically with your app, so that you could literally drop and go.

More best practices and patterns

We’ve done a much better job than before of “lifting” the documentation to a higher level of abstraction - one that shows how the system works rather than describing it with words. We know we can do better, though - there are emerging high-level idioms and patterns for using CloudMine, and we want to encourage the use of these best practices.

Final Words

We’re creating our documentation using the same process as the product: constant feedback, iteration, and redesign. We believe that’s the quickest and most reliable path to high quality. This isn’t the last you’ll see of us re: documentation, so stay tuned.

PennApps: The Hackathon that Changed Everything (for me)

derekmansen — Fri, 21 Sep 2012 14:40:05 -0400

Okay, I’ll come right out and say it: I wasn’t totally on board with the whole “hackathon” thing. I like to code, and I love my job. But I do work a normal work week, and spending my weekend doing a lot more of the same wasn’t first priority for me.

That is, until last weekend, when I had the pleasure to attend PennApps, the world’s largest student-run hackathon. Some highlights for me: doing my first live demo of CloudMine in front of a room of about 400 people, finally getting to meet the most OG CloudMine employee (hi Tess!), staying up til 5 am helping a team debug their iOS project in the 11th hour, and listening to a hysterical story told through the medium of a git repository.

In short: I’m all in.

If you’re on the fence about attending these events, allow me to give you some motivational reasons why you might want to attend.

Make meaningful, long-lasting connections.

In fact, CloudMine’s founders met at a Startup Weekend (an oft-told story that you can read about here). You never know who you’re going to meet at these things - and when the crowd is all self-selected hacker types, your odds get a whole lot better.

See how the pros work.

How often does a student get a chance to pair program with an engineer from Facebook? You can get some real insight into coding just by watching somebody who’s done it for a long time. The first time you see somebody dive into your code and quickly find the bug that you just spent two hours chasing down, you feel a bit more than humbled!

Discover what you’re interested in.

Pick a project. Start writing it. Finish up for the weekend: did you enjoy it? Great! Keep working on it and it might be the next big thing! But, maybe you hated it - well, you only spent the weekend on it, and there’s always the next one. Try something else next time, it’s fine!

Practice.

Having 48 hours to conceive of a product, deliver it, and present it forces you to cut out the fat. You need to concentrate on what you can do well, right now. It’s great practice for a life where these kinds of events are commonplace (working for a startup). And, as the teams using CloudMine discovered, it’s great being able to cut out a massive chunk of the work when you’re on such a strict deadline!

Okay, what else?

From the mentoring side, it was wonderful hanging with some of the sharpest minds I know, pooling together our resources to help the students build something meaningful. There was a great sense of camaraderie: we were all in it together. (Except for: what’s with all college kids using vim, anyway? Let’s move over to the big girl tools like emacs. Sorry, couldn’t help myself.)

As for me, I can’t get enough right now. I’m on my way to Boston today for Art Hack Day and am super excited to see what kinds of hacks they’re going to come up with. If you’re in the area, stop by and say hello!

iOS Resources by Developers, for Developers

localeverywhere — Wed, 12 Sep 2012 10:47:56 -0400

Being an individual developer can mean that it’s difficult to write iOS apps because some of the tools to do so can be costly or simply hard to find. Sure, you may be able to get along by writing little bits of it here and there on your own time - but there are many existing services that help make the development and deployment process much easier. That’s where App Dispatch comes in.

App Dispatch is a community focused on connecting mobile app developers to the tools and services that make iOS apps a blazing success. If there’s a feature you want to implement, from a simple push notification system to a complex data-store, there’s no reason to reinvent the wheel.

For its inaugural launch, we are partnering with App Dispatch to give individual developers a leg up on the competition. With full access to our backend platform your app can be developed, deployed and maintained all from one intuitive interface and for much cheaper than our normal plans.

Check out the App Dispatch site to learn more about their offers.

CloudMine goes SURFing

localeverywhere — Wed, 29 Aug 2012 13:19:32 -0400

From getting our beginnings at a Startup Weekend and exploding on to the stage with help from the DreamIT accelerator, we’ve been able to spread our startup roots. As part of our commitment to the startup community at large, we’re going to be supporting the SURF Incubator space for digital startups. All of the SURF resident companies will have complete access to our platform for developing, building, and deploying their apps.

SURF is dedicated to advancing the ideas and passions of technology-focused entrepreneurs - who now won’t have to worry about maintaining a backend. By bringing together a collection of great minds from different technical and business backgrounds, entrepreneurs within the SURF community can solicit resources as needed and grow their businesses on their own terms. Check out their site for more details about the program and how to apply.

App analytics and public Access Control Lists!

localeverywhere — Fri, 24 Aug 2012 11:55:29 -0400

With the summer coming to a close we wanted to share what we’ve been working on over the past month.

What’s new?

The dashboard now has pretty graphs to show analytics for all of your deployed apps. Go ahead, be sneaky and dig deep to find out what your users are up to and see when the real action is happening.
Give your users the ability to share content with anybody who is logged into your app without the need to manually maintain a user list by using public ACLs.

Check out the docs for in depth details on how to use all of the new goodies. Until next time, code on!

Forrester: "Backend as a service, the new mobile middleware" – Explained in graphic detail

unleadedthought — Mon, 20 Aug 2012 11:25:00 -0400

Being the designer amongst 7 hardcore developers who specialize in different niche worlds of software has been an interesting experience. Because designers and developers inherently solve problems, I thought it would be beneficial to merge these two areas of thought. Leveraging my understanding of visual storytelling and our developers’ understanding of french bistros – we’ll get to the bistros later – I designed an infographic to help explain backend-as-a-service, which can sometimes be nebulous.

A little background

I am wrapping up my second month as CloudMine’s UX/UI designer. Previously I was a web analyst in Boston serving clients such as Comcast, Liberty Mutual and the Make-A-Wish Foundation. Most recently, however, I obtained my Masters in Industrial Design with a focus on Human Centered Design.

Developers work very differently than how I am accustomed. To start, they speak in a completely different language. Many times it’s like being in a French bistro when I only know a little bit of Spanish, catching a word or phrase here and there. It’s not too soon that I realize they are speaking 19 different languages, and I decide that simply eating a croissant and sipping an espresso are much easier tasks. Secondly, the bulk of their work has to happen at the screen of their computer; printing out thousands of lines of code isn’t really going to help their workflow – not to mention the resources of the Venturef0rth printer.

Wrapping it up

There are clear professional and cultural differences that I have come to realize, but it’s humbling to know that these differences are not siloed to my experience at CloudMine, nor are they particular to the world of design and development. Because it is sometimes difficult to explain exactly what it is we do at CloudMine, and because backend-as-a-service (BaaS) is still a new industry, I’ve designed a visual overview to help convey what BaaS companies do – that is, without going into the oft foreign language of development.

This infographic should serve as a first pass into a visual explanation of BaaS. This visual is built off the basic storyboard of a smartphone application not dissimilar to Instagram. Providing an overview of the multiple stages involved in developing an application, the graphic highlights the specific areas of development that make up the bulk of the work when coding an app. And in the end, it shows what a backend service provider would take care of for our users (the developer).

Enjoy! Please leave any comments below, or send us a tweet or an email.

We're a Top 10 Mobile App Development Tool!

localeverywhere — Mon, 13 Aug 2012 20:40:32 -0400

Dailytekk, the curators of cool and useful tech, picked us as a top ten resource for mobile developers! We’re quite excited to have topped the list as one of the few BaaS players to make the cut.

Built to handle what you’re building

Variety is the spice of life and that’s the kind of ecosystem we’re supporting.

From the fresh take on Mr. Men and Little Miss with the Sightings social photo sharing app starring numerous Little Miss favorites, to a CME
certified medical education and point-of-care tool, our platform makes sure the gamut of services you offer keep chugging along - at 1 user or 1 Million.

We love getting dreams off the ground and liberating big data. Tell us what’s holding your ideas from seeing the light of day - email team@cloudmine.me - and we’ll pave the way for your projects to rise up and shine.

Storm Clouds in VA, Happy CloudMiners all over

ilyabraude — Sat, 30 Jun 2012 16:38:19 -0400

One of the benefits that our users enjoy is running their applications on our infrastructure platform. A great example of how this pays off was seen during the Great AWS Outage of 2012 recently. Our API, and more importantly our users’ apps, stayed up despite Amazon’s system-wide failures.

It all started on Friday night when our website and API monitoring systems starting sending us emails that the website is misbehaving and requests were timing out. An investigation commenced.

Reports started flowing in on twitter that the Internet was down (i.e., Netflix, Instagram, Pinterest, and others).

The AWS status page started describing outages in RDS, some availability zones, and EBS systems, attributing them to a power loss due to electrical storms in the area.

Clearly Amazon AWS was not having a good day.

Impact

A quick check confirmed that the website was indeed down and was having issues accessing the database instance powering it (running on Amazon’s RDS).

I quickly spun up another database server from a very recent snapshot but due to the prevailing RDS issues, it took about two hours to start. Once it did, the website was back up and running normally.

Our primary concern is the API servers. None of our users’ critical operations are dependent on the website, but all their apps are powered by our APIs.

As it turned out, one of our API database servers stopped responding as well.

But there was no need to panic! Our system is build to handle these kinds of failures. Other database servers picked up the load and the API servers kept happily serving requests (though there were some brief ELB issues as well).

The biggest impact on our API servers was that some requests were taking a longer time to respond because of the database failover, but they did eventually respond. Taking the failed API database out of the configuration immediately resolved those issues. And we’ll make sure that this won’t be a problem in the future.

A potential crisis averted! And some lessons learned.

Takeaways

Running on the cloud is not trivial. In this incident, we had two database servers fail completely (and possibly irrecoverably) with no adverse affects. But most developers run only one database server or application server due to complexity and cost of redundancy. A single server failure would then be catastrophic for that developer.
Our API uptime is very important to us because lots of developers depend on us to keep their apps running and their end users happy. This time, our redundancy and failover provisions kept our primary Amazon servers up and serving customers. However, had that failed, we were ready to failover the entire stack to the other cloud providers. While others went down, sites and apps powered by CloudMine stayed up.
Always, always have backups. We recovered our RDS instance from a fresh snapshot, and had snapshots of our API database ready to spin up if the need arose.
Both of the DB servers that failed (RDS and API) were on the same availability zone - us-east-1d. It seems that this zone got hit harder than the rest. The key to CloudMine staying up and not loosing any data was having multiple redundant API and database servers in several availability zones.
Rebooting misbehaving instances in AWS when there are system-wide issues tends to make things worse. It takes many actions and resources to spin up new instances and/or EBS volumes and more load is placed on an already hurting system. In these cases, rebooting usually fails anyway or is not the quick fix people expect. Plan for other contingencies.

Bringing the BaaS

zhenyag — Fri, 22 Jun 2012 09:11:00 -0400

From our humble beginnings at a Startup Weekend Philly to being a Global Sponsor of all Startup Weekend events, the past nine months have been a whirlwind of growth and activity for us.

Embraced by developers — who are now running more than 1,500 apps on our platform — their feedback was instrumental in ironing out the kinks of developing apps on our backend. Months of strengthening the core have lead us to today.

Introducing CloudMine 1.0: a backend stack capable of supporting companies building something new, digital agencies working on hundreds of apps for their clients, and large enterprises vying to expose their legacy data to mobile.

How backend-as-a-service works

Fast, flexible and simple to use. We take care of the entire mess of infrastructure and web service software development that stands between your idea and a finished app. Avoid building and scaling custom server-side software, maintaining a codebase that your customers will never interact with, and putting out server fires – just talk to our flexible API using HTTP or one of our numerous mobile and web SDKs. We’ll fight off the hassles and deal with the headaches of making sure your app is running whenever, wherever.

Build your way, just faster

All it takes to get started developing on CloudMine is dropping our SDK into your codebase. Everything else is already taken care of, leaving you free to flex your development and UX muscles. Want to develop for mobile? Download our iOS or Android SDK, or do it yourself through our REST API. Want to build something for the web? Use the JavaScript SDK and upload your HTML, JavaScript, CSS, and image assets right to our servers.

And best of all, there’s no data models or schema locking to worry about because database structures should not influence the design of your apps. Code your model objects client-side the way you want, give them to the CloudMine SDK of your choosing, and we take care of the rest. You can even host custom code on our servers to be executed on your data whenever you want, which is great for doing that heavy processing or third-party API integration that would typically require your own server.

Whichever platform you develop for, the same robust feature set will be available across the board. So you know that crazy location-based, social picture sharing chat room you wanted to build? Or all of that data you have been housing while dreaming of a way to get it mobile? We make all that possible.

Easier to get started

Just like on a date, first impressions are key. Taking that to heart, our entire site went through a major clean-up so you won’t feel bad for referring friends to check it all out.

The polish didn’t stop at the surface though. Steve, Artur, and Nic tore up the CloudMine Dashboard. The new version makes it much easier to view and manage all of your active apps, data, and users. It also provides more contextually relevant assistance when getting started so you can get to the good stuff faster.

There’s lots to be discovered, so sign in and play around. We’d love to hear your feedback on the improvements!

Happy Mining!

Storing Private User Data with our JavaScript SDK

artursapek — Fri, 15 Jun 2012 10:01:00 -0400

Most apps require storing some sort of user data, whether that’s login credentials or sensitive data. The previous post already gave a high level overview of how to use our built-in user account management, so let’s dive in a step further and see how to secure user data. For this example, we’re going to use a sample app built using our JavaScript SDK.

Keeping Private Data Safe

As an example of how to secure data, let’s take a look at a simple web app. We built this quick todo list app using our JavaScript SDK. The finished product is available for you to play with as well.

The app features two views: a simple login/registration page and the actual list itself. The todo items each have an assigned priority level (an integer between 1 and 3) as well as an optional due date. To keep things simple, this is expressed as an integer in hours from when the task is created.

In this view we can see a few items of varying priority. It looks like we’ve already paid Derek back for sushi, so that’s good, but this post is still unfinished with a looming deadline, so let’s get at it.

Building with our Javascript SDK

CloudMine takes care of the data storage and other essentials, so all you have to do is use our brand new evented JavaScript SDK. We just need a copy of the Javascript SDK and jQuery (or save yourself the download by linking to a hosted version of jQuery), plus some sprites for a colorful UI. To begin, configure a new instance of cloudmine.WebService with our app’s API Key and App ID.

User accounts

Once the SDK is initialized, we can just start making API calls. The new JS SDK supports Restler-style chaining, so we get to write these with clean, semantic syntax. Here’s a login request, which is triggered when the user clicks the Login button in the UI.

We can easily show error messages from the server. Here, a bad email will cause show_error to flash this response:

We’re also using these same fields to offer registration. Just for the sake of the demo, we’re only asking for an email and a password again. Here’s how we might register a new user with CloudMine.

Notice how we are taking advantage of callback chaining. All you really need is the createUser call, but the extra stuff makes for a more user-friendly interface. We can listen for specific successes and errors and react to them differently. Here we chose to return the server’s raw error response when the email is already in use, but you can return our own message if the email is invalid. Since we also changed the UI to indicate the request is pending, we can reset it in the event of any error at all.

Storing and retrieving todos

Once we’re logged in, we can query for that user’s data to see if they already have a todo list.

Sending new and updated todos is just as easy. Here we’re sending a new item that was just created, stored in the object_data object.

Changing data

When the user checks off an item, we can use the update method to change one of its properties.

Deleting data

We’ve also added little buttons. Here’s how simple it is to remove an object both in frontend and in backend by calling one function:

To see more examples, including saving user sessions and logging out, you can fork the finished app from its repo.

User Account Management For Mobile Apps

derekmansen — Thu, 31 May 2012 07:46:00 -0400

We’re pleased to announce a dedicated set of tools for managing user accounts on all apps developed using our platform. All examples in this tutorial use the CloudMine iOS SDK, however, all of the operations are also available through our REST API.

Creating Accounts

The CMUser class contains all the methods you need to manage user accounts. To create a new account, initialize a new CMUser object and call the createAccountWithCallback method.

Login

Once the account is created, the user can be authenticated by calling the loginWithCallback method.

There is a shortcut for creating an account and logging in with one operation called createAccountAndLoginWithCallback:

Once the user is logged in, you will need to configure the CMStore for making authenticated requests.

From now on, all requests for user-level data will be authenticated with the user’s credentials.

Logout

When you want to terminate a user’s session, call the logoutWithCallback method.

Password Change

Users now have the ability to change their password. For security purposes, the user must provide their old password along with their new password.

Forgotten Password Reset

If a user forgets their password, they can request that an email be sent with instructions on how to reset it.

How to Store and Retrieve User Data

There are many different methods for retrieving data from the CMStore. Each method has two versions: one to fetch app-level data, and one for user-level data. To store or retrieve user objects, call the “user” version of any method in CMStore: as long as the CMStore has been initialized with a logged-in user, requests will transparently be authenticated with that user.

For example, to retrieve all user objects, call the allUsersObjectsWithOptions method.

For more information, visit our iOS Library Documentation.

iOS SDK Refresh

localeverywhere — Fri, 25 May 2012 12:21:00 -0400

We took your input, with just a bit of our own work sprinkled in for good measure, and updated the iOS library. All of the updates compile and translate into easier and faster development for your iOS apps.

What’s New?

There are upgrades across the board to make development and deployment faster. However, the three major changes that stand out are:

Run server-side code from any operation in the library. All operations can now access result data from server-side code snippets, as well as any metadata returned in the API call response. This gives you the power to use the power of server-side processing or plug in other services. What we’re saying is - build whatever you want.
Upload files without keys. Even though we love gossip, there’s no need to tell us all the details. Uploading a file without a key will automatically create one for it once it’s on our servers.
Sort object query results. Sometimes the natural order isn’t what you want. Object queries can now be sorted by any field on the object, in ascending or descending order.

Backwards Compatibility

You will need to change the way callbacks are handled by your apps after upgrading to the new library. Once this change is made, however, all future versions of the library will be completely backwards compatible. The example below outlines the change.

Previously each callback would be passed parameters explicitly, like so:

Now, each callback takes just one object that contains all the properties you may need:

Handling callbacks in this way allows us to add new attributes to our responses without breaking your code in the future. We’re sorry for the trouble in the mean time!

Get Building

Take a gander at the video for a quick intro on how to get started developing with the new library. The iOS documentation in our Developer Zone is also a great place to fully familiarize yourself with the library and all of the changes.

As always, feel free to email or tweet to us if there’s anything we can help with.

Application-Level Data Security

derekmansen — Thu, 19 Apr 2012 10:17:00 -0400

We’re pleased to announce an all-new security feature for the CloudMine platform. You can now use our new API key rules interface to secure application-level data, allowing you to restrict access to your data without requiring your users to log in.

Why?

APIs like CloudMine usually restrict access to their data via the use of an API key, or token, that is sent with each request to perform authentication on the server. The problem with this is that the key must be embedded in code. This offers a small level of protection from malicious users, but a motivated person could still decompile the app and get the key without too much effort.

With this feature, you can restrict access to some (or all) of your data using our rules system. You can make certain objects or files read-only, or only allow users to create objects (but not delete them). Security is validated on our servers with each API request. One common scenario is when an HTML5 web app needs access to your data. This works by embedding your key in the app’s JavaScript code. However, keys embedded in JavaScript are easily extracted. In this instance, you should create a new key with read-only permissions and use that to access the API.

How It Works

If you just want to jump in and play around with the new feature, head on over to your CloudMine Dashboard. Read the quick blurb about how the system is organized, make a new API key, and apply some rules to it. You can use the API Console to explore how your results change depending on which rules you’ve defined.

When you’re satisfied that the rules you’ve created are what you want for your app, you can either apply them to your current API key, or redistribute your app with the new key. If you need more detailed information, visit the App-Level Data Security section of our API documentation.

Start Developing!

We have a lot of pride in the new features we’re bringing you, and we’re excited to see how developers end up using it. If you have any questions or comments, don’t hesitate to drop us a line on Twitter or via email.

About Sexism In Tech

derekmansen — Tue, 20 Mar 2012 16:37:00 -0400

Some unfortunate events occurred during the afternoon, related to some very poor and offensive wording in the flyer for an event that we were sponsoring. A short summary of what happened:

An event posting for the Boston API Jam was created containing clearly sexist language. We were listed as a sponsor of the event at the time.
The sexism in the event details was pointed out to us by many followers on Twitter (special thanks to @coolaunterin!)
Before the flyer was posted, we were unaware of the specific wording that was going to be used in the flyer.
We, and other companies, pulled our sponsorships from the event.

All of us at CloudMine agreed that this type of language is not acceptable, and we made an effort to contact the organizers of the event to get this changed as quickly as possible. Sexism in tech is a serious problem. Events like what happened today are, unfortunately, not uncommon. Catering exclusively to men in a sexist manner in your marketing materials is not only wrong, but it undermines those trying to make real progress. It hurts everyone when something like this happens—it can make women feel like outsiders in their own field, and it normalizes this type of behavior as okay (which it absolutely never is, even if there was no intention to hurt).

Having said that, we sincerely apologize for any offense that was caused. We never would have posted something like that, and do not endorse anyone who does.

Since we are no longer sponsoring this event, we now have extra funding to sponsor a different event which is more aligned with our views. We love hackathons—our company born at one—and we’d like to put this money to good use at an event that will bring all hackers (women and men alike!) together. Give us your suggestions in the comments or on Twitter (@CloudMine).

Announcing the CloudMine iOS SDK

marcweil — Fri, 16 Mar 2012 13:09:19 -0400

Performing manual URL concatination sucks. Client-side caching and dealing with the implications of a lost network connection sucks. Having to manually break down model objects into their JSON representation sucks. For all these reasons, we are happy to announce that the first release of the CloudMine iOS SDK is available, and you no longer have to deal with any of that. Getting started with CloudMine couldn’t be easier. Just download the SDK, drop it into your project, and go. We even have a video walkthrough of how to add the framework to your XCode project (since XCode doesn’t make that as easy as it should be).

The SDK is also open source and licensed under the MIT license. Its full source and building instructions are available on the GitHub repository if you get the urge to hack on it yourself.

After adding the framework to XCode, get started by configuring CMAPICredentials and making your model objects extend CMObject. No more messing with Core Data! We have an overview of the SDK you should check out as well.

Walkthrough Requests

Is there something that you’d like to see explained in a short screencast? Drop us a line and let us know!

Walkthrough: Adding the SDK to XCode