CloudMine Blog

In honor of Cinco de Mayo, we wanted to provide a short list of the mobile platform ‘must-haves’  for the successful enterprise mobile app developer: (hint: tequila is not required)

1.     Ability to secure your data & users - in a post-Sony hacked world, securing user data has never been more relevant. When developing mobile apps, you need to consider the following scenarios in securing your data:

Will the data persist? If so, where? In an purpose-built database, or within an existing existing enterprise system?

What level of encryption will you require? Do you need to encrypt at storage alone, or should you use encryption in-flight?

How will you ensure that your users are authorized to access your app?

How will you ensure that users view data they are authorized to view?

Are you staffed to handle threat detection? Monitoring? Built-in encryption?

Look for more on this topic in future blog posts...

2.     Broad ecosystem of partners - Building a best-of-breed mobile app requires your mobile platform vendor to work with a variety of best-of-vendors. The following vendors add up to be a best-of-breed mobile solution:

Front-end (client-side) tooling (ex. PhoneGap, Xamarin, AppGyvr)

Backend services layer (mBaaS // BaaS)

Identity management (IDM)

Enterprise Mobility Management (EMM)

API design & management

Infrastructure & hosting providers (IaaS)

Specialized professional services

Look for a series of blog posts to highlight CloudMine best-of-breed partnerships...

3.     Integration to enterprise systems - Mobile coupled with the internet of things (IoT) has evolved into 2 key use cases around data integration:

Bringing existing business data closer to the ‘edge.’ Mobile provides businesses with the ability to derive additional value from existing data by delivering it to users in the context of their daily interactions (the ‘edge’). That data drives new brand experiences, more intelligent consumers, and instant reference capability.

Collecting & aggregating new information from the ‘edge.’ Both mobile and IoT have uncovered a tremendous opportunity to collect new types of data from unprecedented, and previously disconnected devices. Enterprises struggle with how to integrate that data back into their mature IT ecosystems.

4.  Logging and disaster recovery - You need visibility into your app’s operations in order to troubleshoot, maintain, and ensure top-notch performance in periods of high demand. You will also need to analyze operations in order to optimize app infrastructure and support audit capabilities in an increasingly regulated world. Moreover, you need a platform that provides full backup and disaster recovery, ensuring that no data is left behind, and your users can feel confident that their app experience, and data will always be intact.  

5.     Support for the modern-day developer - Until recently, there was a notion that building an application required two distinct engineering profiles: front-end vs. backend, with each resource falling into a silo with regard to programming language and implementation. For example, an iOS app could be built natively on the front-end using Swift, and complemented with backend logic written in Java, or Groovy. Two distinct technologies, and two distinct skill sets.

Enter JavaScript, and tools like PhoneGap and Node.JS which allow JavaScript developers to build the front-end (PhoneGap), and backend (Node.JS) using a single language. Add the simplicity and light-weight nature of mobile apps, powered with the rise of the API economy, and organizations are able to build and deliver connected applications quickly - with a unified resource and tech stack.

CloudMine blends these 5 critical components to deliver the industry’s most secure enterprise mobility platform. We set out to solve the tough problems around mobile development so you wouldn’t have to. Why reinvent the wheel? Contact us to learn how you can jumpstart your mobile development project.

We are fresh off the plane from Chicago and HIMSS15, the world’s largest gathering of healthcare IT professionals. This year’s conference drew over 45,000 people to the Windy City and proved to demonstrate the state of healthcare technology is at a critical juncture as consumer-driven trends are beginning to impact continuity of care, quality of treatment, and the overall intelligence that providers and related companies are able to obtain through the new connected world. In case you missed the event, here are some key takeaways:

Interoperability is still a monumental hurdle in breaking down walls and promoting continuity of care. Healthcare organizations continue to struggle with integration across a variety of fragmented technologies, organizations, and data types (business vs. clinical). There were several middleware vendors presenting on the topic of integrating business systems with the more regulated and sensitive patient data. These vendors stressed the importance of obtaining connectivity that is stable and well tailored to business systems, while bridging communicating across networks and ecosystems in standards such as HL7 for highly sensitive data. Further, through the Interoperability Showcase, HIMSS was able to demonstrate live, standards-based integration, allowing attendees to envision a world where patient data follows you through a treatment cycle, informing all relevant stakeholders of critical patient information. This also proves to align data to workflows, and abstract IT systems from true course of treatment.

Patient engagement has long surpassed the world of portals and self-service admin. On Sunday, we were proud to take part in the Mobile Health Symposium where healthcare leaders from across the globe gathered to discuss key trends and issues regarding mobility’s impact on the industry. Patient engagement was a constant theme, but not in the traditional “build me a mobile app” sense. This year’s discussion was focused on engaging the patient through non-application/portal methods. For instance, a presenter from Geisinger Health System talked about relevancy of patient engagement, and the need to send the right information, in the right medium, at the right time. An example: Patient Ann Jones usually takes insulin every 12 hours. Ann logs her blood sugar through a mobile app at each injection, providing real-time updates to her doctor. Unfortunately, Ann was out with friends and lost track of time... By hour 14, Ann had not logged her blood sugar or indicated that she had taken the required dose of insulin. Luckily, her healthcare provider can monitor her activity, and send a text/SMS as a reminder. Moreover, they can send a push notification, email, or automated phone call - configurable to Ann’s preference. Now, Ann has the information she needs, at the time she needs it, by the method she prefers.

Data is everywhere - and the pace of innovation will continue to generate data exponentially while challenging current security & privacy standards. With the rise of connected devices and the Internet of Everything (IoE), healthcare providers have an unprecedented opportunity to collect real-time, massive amounts of clinical data. This opportunity is giving rise to a new breed of technology vendor who blends instant connectivity (via API’s) with secure data aggregation (and storage) in order to feed industrial strength big data repositories for further analysis, data science, and trigger-based workflow. It was clear this is still a nascent concept, as traditionally the API and data aggregation/storage functions would be offered by a distinct, best-of-breed vendor. Niche vendors would then empower organizations to leverage this data in the forms specified: data science and inference, analytics and reporting, as well as workflow. Several vendors are beginning to blend functionality with the objective of providing a more robust stack to handle the IoE-fueled big data use case. Adding to this complexity: a lack of specific standards to address the way in which connected medical & personal health devices collect and communicate this critical data back to the enterprise data warehouse or system of record. The FDA recently published guidelines to begin to address this challenge, but we are in the early days, and can expect to see meaning changes ahead.

After absorbing the wealth of information at HIMSS15, our team at CloudMine has never been more excited about our platform offering, and the direction we’re headed in months to come. Here’s a peek at how CloudMine addresses the challenges facing modern healthcare IT leaders:

API design and management functionality - allowing you to expose and gather key healthcare-related data, tailoring connectivity to use case

Data encryption - including both in-transit and at rest (on disk) to ensure security throughout your solution stack

HIPAA ready - so you can focus on what to do with the data at hand and how to engage your patients in the right way, medium, and time

Application logic & hosting - enabling you to build rich and performant applications for web, mobile, and connected devices alike

Systems integration - powered by best-of-breed middleware vendors with packaged integration to leading business and healthcare systems

Unparalleled scale - through deployment in the cloud, enabling your APIs and applications to handle the “high’s and low’s” of transactional volumes

Networking in Android is hard. The standard pattern has been to pass a callback to the service performing the request, which performs some action on completion. Often these callbacks are anonymous inner classes created inside your Activity or Fragment. This works fine - until the user rotates their device, or hits the home button, or switches to another app. Then your Activity can be destroyed before the callback returns, resulting in your activity context leaking and your callback updating an Activity that no longer exists.

The issue is not the callback pattern itself - the issue is that the callback is tied to your Activity, but the lifecycle of the request is not. Google has released a networking library called Volley that allows for cancelling requests, tying them to the Activity lifecycle, and we have integrated it with our CloudMine library.

Volley works by creating new Request objects which encapsulate all the information needed to make and respond to an HTTP request - URL, headers, body content, success and error listeners, etc. These requests are then added to a RequestQueue, which performs the request. The Requests can be canceled from the RequestQueue, which is what allows us to tie the lifecycle of the Request to the lifecycle of the Activity. An example of this is given below:

The recent unveiling of iOS 8 introduced a new programming language: Swift.

Many are wondering when their favorite services will support this innovative new language. For CloudMine, that time is now. With the new CloudMine Swift library, it's easier than ever before to upload, download, and manage your data and access other CloudMine functionality.

To use our library in your Swift projects, import the header file into your project's bridge header.

You can download our library here, or install it using CocoaPods. A bridge header is a file that allows a developer to use Objective-C libraries in her Swift code. Be sure to designate this header in the Swift Compiler section of project's target. For a more complete discussion, see this StackOverflow answer.

Both Swift and CloudMine are based upon the principles of speed and simplicity. Here are some quick examples to get you up and running with CloudMine:

First, create a CloudMine object to facilitate the transfer of data:

This can be created wherever the object is needed.

In the past with Objective-C, this is how you would save an object:

To save an object with Swift you simply call the save method on your object:

Here's a shorter version:

Object retrieval in Objective-C:

The same in Swift:

This is a guest post by Maximilian Maksutovic, Biomeme's software lead responsible for iOS, web, and Arudino development. Biomeme is a startup developing a smartphone attachment that can perform realtime DNA analysis, and is backed by Mark Cuban and Dreamit Ventures. Product systems will sell for around $2,000, but the company is hoping to bring it to drugstores around the world for around $200 in a few years’ time. Just a few applications include tracking diseases, testing food and water for pathogens, and serving as a detector for bioterror agents.

Being a relatively young developer, I am fortunate enough to work in an era of incredible tools: sophisticated IDEs, excellent compilers, and every sort of library and API imaginable. The one thing I am most thankful for is cloud-based backend systems. I can imagine some older, more stubborn developers would like to say that building and maintaining custom servers "builds character." However, I also understand that most startups, including Biomeme, do not have the time or money to properly build these systems. In addition, these systems are often painfully overkill unless your startup is serving large amounts of users and data concurrently; which, let’s be honest, it isn’t.

My first introduction to cloud-based backends was Parse. I used it for my thesis software engineering project, where I built a self-guided tour for iOS of the Fairfield Osborne Preserve at Sonoma State University. The app consisted of a map with the trail of the preserve overlaid on it. As you would walk on the trail, the app would trigger certain geopoints that would attract the user to a specific cultural, geological, or ecological point of interest. The user would then be asked to look around their current position and be quizzed about certain features regarding the point of interest.

Using a cloud-based backend made this project feasible in a very short amount of time. It took only 4 weeks. I was able to capture geopoints for both the trail and points of interest. I could easily tag the data necessary for the internal database for the app. Using this system also allowed for my biology major collaborators to have a central place to upload additional content (the quiz questions, detailed narratives, additional photos/maps/scientific data/etc.) without the need for email attachments and USB drives.

Prior to graduation I was hired at Biomeme, an incredible startup that enables anyone to do mobile real-time DNA analysis on a smartphone. We had some initial talks about the data management that would be required: we would have to collect and store both experimental and patient data. We would need to configure, save, and share different tests. We must have been able to display data on different devices, porting it to the web, integrating with disease monitoring sites such as collaborate.org, HealthMap, and SAGES, as well as electronic health records. Working with such sensitive data, I knew HIPPA compliance was going to be an issue and needed to be addressed from the start. My main problem with Parse is that it had directly stated it is not HIPPA compliant, and hadn’t made any promises of being compliant in the future. Regardless, we were at such an early stage that I told the team we should use Parse to get off the ground. I was thinking that, by some miracle chance, I could address the HIPAA compliance with some other solution or subcontract someone to help me do it.

When I moved to Philadelphia to join the team, we were working out of VentureF0rth, a co-working space that also played home for CloudMine. I hadn’t heard of them, but after some introductions they told me they had an open source API that was similar to Parse’s. I was certainly interested, especially considering that they said the magic words of, "Oh, and we’re HIPPA compliant." After building up their MVP to our first beta, it came time to start the data integration.

After a very clear and simple "getting started" guide and tutorial, I noticed one thing right away working with CloudMine: the API felt so natural to the iOS SDK, as if it was written by Apple engineers. My biggest pet peeve with Parse was subclassing, let’s compare the difference: Parse Subclassing:

After setting up the class, you then have to "register" the subclass in your AppDelegate:

Now let’s compare how we would implement this ISCoordinate subclass in CloudMine:

So let me explain some of my resistance with Parse. For the subclass you need to add this class method +(NSString) parseClassName, which was needed for my purposes just to return a string. This certainly seems a little superfluous. Next, the class has to delegate to <PFSubclassing>, which seemed cryptic to begin with. If one looks under the hood to better understand this process, the result is even more incomprehensible. You also need @dynamic instance variables, which are not well explained. Finally, you are forced to create a Parse instance method which requires the following line: MySubclass object = [MySubclass object]. The [… object] message, again, seems rather cryptic; and again, looking under the hood is even less helpful.

With CloudMine, the code is standardly defined, using the default initWithCoder and encodeWithCoder methods. This is helpful because now all of your CMObjects are compliant with NSSerialization. With this, we can store all of our objects locally in case the user does not have an active Internet connection, and the app can continue to function without an active connection. Moreover, nothing about subclassing with CloudMine feels out of the ordinary; I feel completely at home making CMObjects just as I would NSObjects. A good API written for a specific platform should feel completely native to the parent language, and I feel that CloudMine does perfectly.

Now, some developers reading this are thinking "Big deal. Every API has its quirks. Every language has its quirks. We just have to grunt, bear it and learn it." Do you want to work with an API that forces its own architecture down your throat and requires a workaround from the developer, or do you want an API that works hard to conform to the language you are working with? I prefer the latter.

To drive the issue further, lets talk about business. Every choice of language, platform, and API has a direct business cost, especially for a small startup. A quick example: Biomeme’s app needs chart functionality, which a previous developer quoted nearly $20,000 plus many months to implement. I looked at the (free) Core Plot API and thought it was feasible, but to make it look pretty and perform well it would take a large chunk of time we just didn’t have. I decided to get a ShinobiCharts license (which was $400), however I had a beautiful Biomeme branded chart running in less than 3 hours. Should have I used a free API? Maybe. Would the extra time learning and the API to deliver a half-baked product been a good decision for Biomeme? Definitely not. The same goes for our cloud backend. Wouldn’t it be an amazing, fun project to build a HIPPA compliant backend hooked up to a Rackspace server, shuttle data in and out using Ruby or Python scripts, and encrypt and isolate the data with OpenSSL? Definitely! Would the massive time sink to do that, --plus the bug hunting, --plus writing the necessary documentation for other recently on-boarded developers be a good decision for Biomeme? Definitely not! All that time I would of taken to build such a solution would take me away from building core functionality of the Biomeme App, delay the ability to demo the system to customers, and delay our chances of making it as a startup.

By using CloudMine, I was able to deliver a brilliant product with all the necessary data being stored and retrieved from the app, hassle free. Better yet, all of the code and architecture I have currently written is completely future-proof for when we want to extend this data to web apps and other platforms such as Android. Best still, once we require HIPPA compliance, all CloudMine has to do (in the words of co-founder Ilya Braude) is "flip a switch" and we are fully compliant. I recently brought on a contractor for some work and he helped augment some data management within the app, and immediately fell in love with the ease of CloudMine’s API. Within a weekend, we had created a perfect, elegant, future-proof solution for shuttling data back to CloudMine, even in scenarios where there is no active Internet connection.

Of course I could have done all of this with Parse. Despite my minor problems, it is a fine API and used fairly extensively across the development world. But without HIPPA compliance and the lack of personal support, the platform falls flat for me. CloudMine is a company that I feel partners with you to help bring your product to a higher level. The level of support that CloudMine provides is second to none, and that is worth every expense of the platform. If I were to receive strange messages or if code seemed to not work right with the API, I could contact CloudMine and within a few hours have a detailed response, complete with code examples.

StackMob, a mobile backend infrastructure company, recently shook the industry by announcing that they are shutting down their service after being acquired by PayPal several months ago. While significant speculation surrounds the situation, there are many customers seeking alternative backend solutions to power their mobile applications. StackMob has offered a CSV data exporter, allowing customers to extract their application data and continue development either on their own, or with the help of other backend providers.

In response to increasing requests, CloudMine has created a CSV/JSON importer to help ease transitions for those who enjoy the many benefits of a cloud-based backend platform. We understand that the migration of mission critical applications is not simply a matter of importing data, so our team is prepared to work closely with you to understand exact requirements, offer objective advice and insight, and help guide you towards your best path to success — even if our platform is not the final destination of your application.

As a long-standing enterprise mobility company we understand the business continuity concerns expressed about the future of BaaS providers. To address these concerns, CloudMine assures both our current and future customers that, in addition to you always owning your data, applications will always have the backend infrastructure they need due to the platform’s portability and flexibility to reside in any environment, in the cloud or on-premise.

Imagine you sign a new client project after giving an estimated delivery of 9 months. Congratulations! But wait -- you're already at capacity and have spent the past two weeks fighting off the major scope creep your new client is stacking onto your shoulders. The stress is piling up and you consider hiring new engineers, but haven't found a match during your preliminary search.

You know this project is somewhat like a first date, and that if you exceed expectations you're likely to be offered a waterfall of groundbreaking work -- but here you are with no idea how to deliver!

Just when you thought there was no hope at all, we're here to tell you otherwise.

What if you could take this 9 month project and have it shipped and delivered in less than a third of the time, without having to go through the exhaustive process of hiring new developers?

From the onset, this is a difficult topic to approach. However, it's something that comes up in our daily lives as we grow CloudMine into a leading technology solution for agencies and enterprises. We've talked with agencies employing teams of engineers all scrambling to get their projects out the door. One agency was so strapped for development bandwidth that it had PHP developers writing Objective-C, HTML/CSS developers cutting their teeth on Node, and iPhone developers building Android interfaces. While it's great to have a team that tackles any problem thrown their way, we can't help but note that there must be a better, more efficient, less stressful way.

We've also had several conversations with prospective partners who are looking to expand their engineering team, specifically by hiring one or two back-end engineers to help maintain large multitudes of server-side stacks that have been cobbled together over the years. While this is the way business has traditionally been done — hire when you want to grow — we're here to tell you there is a new, technological solution to your problem. First, however, let's take a moment to run down some bullet points on traditional hiring and on-boarding processes and how they may stack up against a Backend-as-a-Service solution.

Hiring Process We've learned this takes an average of 6-10 weeks (per engineer) and a tremendous amount of time, energy and effort from many members of the current team. Additionally, hiring is often responsible for delaying engineering progress. Sourcing candidates, first-round phone interviews, face-to-face meetings, offers, negotiations and finally, acceptance -- this is a long arduous process to endure for each new hire especially when in the middle of crunch-time.

On-boarding, Training & Ramp Up Time On-boarding can take, on average, 3-4 months. What will your new hire be responsible for? How will she blend with an existing team? Who's going to take time out of their workday to train the new employee and bring her up to speed on current projects? How long does it take for a new engineer to become comfortable in her new environment, with her new project and her new mission? This last piece varies greatly person to person.

Salary, Benefits & Equipment It's a known fact that full time employees cost significantly more than pure salary expenditure. Taxes, healthcare, 401k accounts and other benefits eat up a lot of these costs. Additional expenses like equipment, office space, digital services and more are also all rolled up in the total cost of a full time employee (Source). For example, here in Philadelphia it costs around $123,500 per year to employ a single full-time senior engineer. And in San Francisco, it's even worse: it can cost upwards of $161,200 (or higher, where competition is fierce) per year.

Actual Development Time, Labor & Costs Once your new team member is hired and brought up to speed it's time to actually start digging into the task at hand. This will include writing code, creating or expanding technical architecture to meet the company's ever-changing needs, and making sure everything is working all the time. Maintenance is perhaps the largest nuisance of all. Servers have to have OS and security patches applied, firewall rules monitored, performance tweaked and re-tweak, and software tested and deployed. And when those servers crash, your employees are pulled off of their primary objectives and sent into crisis mode to discover and fix whatever went wrong. All of this costs significant time and money that would be better allocated to improve the product in ways that more directly affect the end user.

Risks of Hiring the Wrong Person Hiring mistakes are often considered the biggest expense a company can face, but these expenses are more than just monetary. Bad hires suck energy from companies and breed distraction, process disruption, and can have strong negative impacts on both company's morale and overall productivity. If done properly, a good hiring manager will know how to choose the right person for the right position; but bad hires happen quite frequently, and as a leader you'll need to be prepared for the fallout. According to one source, one bad hire could cost a company two and a half times their annual salary, turning a $100,000 salary into a $250,000 expense. Crazy! (Source)

There is another way

When you make the choice to step away from all this nonsense you'll find that there's a much better option. One that doesn't require seeking out talent, crossing your fingers that there's a culture fit, waiting for ramp-up, dealing with churn, managing any other unforeseen difficulties thrown your way, and then finally hoping the product gets delivered on time.

By leveraging CloudMine's solution and expertise, you and your company are free to create what makes you and your product unique without needing to scale your back-end engineering team. Gone are the days of breaking your back to provide your customers with the data they need on the device they want. Simply plug existing data sources into CloudMine and your information is immediately available to be accessed by any endpoint imaginable: mobile apps, APIs, wearable computers, smart watches— the list is endless.

Any device. Any information.

Let CloudMine be your entire back-end and data integration suite, ready to go out of the box. Say goodbye to sourcing resumes, awkward interviews and "hoping the newbie works out", and say hello to a new world of product-oriented bliss.

Come talk with us to see how we can help.

This guest blog post is written by Geoff McCleary. Goeff is the VP and Group Director of Mobile Innovation at Digitas Health, consulting with key pharmaceutical clients on important marketing & policy issues across a number of fields including social media and emerging channels. In addition to these responsibilities, he is also a leading industry mobile marketing evangelist, advising internal teams and external clients on Mobile Marketing strategy and programs.

Every day I try to take a walk at lunch. Not too much, a mile or two to push my step count up for the day. Enough that my fitness-tracking band may see fit to reward me near the end of the day with a celebratory fanfare of blinking LED lights and a badge on my dashboard for a job well done.

During that walk, I invariably sync my data to my phone, check Facebook, or send out a tweet or two. On a rare occasion I may even check-in at a landmark or store I want to look up later when I have veered too far off course. When I do (pardon the geek moment here) I tend to look up and imagine all the bits and bytes of data zooming overhead into the virtual clouds for me to access later.

It’s tough not to take for granted, especially when it’s baked into so many of the services and apps we use today. With over 60% penetration of smartphones and tablet ownership rising higher every day, the need for multi-screen access is clear. In fact, it’s become such a standard in apps like Facebook, Twitter, Chrome, etc. that I actually take it as a personal affront when a service I use doesn’t provide it.

But that’s the enterprise. I should expect that from major global brands, right? I shouldn’t put that expectation on my client’s brands and properties; that is an enterprise issue. The sheer number of meetings we would need to have to discuss setting that up are prohibitive. Let alone actually deploying it. Right?

But now my client’s customers have an expectation. Provide a little info, enough to login, and now they can share, save, manage and modify content and experiences for convenient viewing when they want, on a screen (or two) of their choosing. Are enterprises turning away customers if they can’t provide this experience to them?

Mobile has brought a lot of changes to the world of brand marketing. Smaller screens — and in the case of tablets, slightly larger smaller screens — and an understanding that customers want to access information whenever they want, on whatever screen they have with them at that time. Not only do they want on-demand multi-screen access, but they want seamless resumable experiences that they can effortlessly continue when they put down one device and pick up another.

Nowhere is this more important than in healthcare. Our customers aren’t buying a product or consuming a good, they are in many cases, trying to save a life. This isn’t a one time visit experience. They seek information across multiple screens, across multiple visits, and they are building a library of information – mentally, digitally and in print. We don’t want to make them work harder; we want them to work more efficiently towards the right solution for their patients.

At any given time, a brand may have a site that supports disease-specific information, a more drug-focused site (both of which will have mobile and tablet versions) as well as an app for patients already using the drug. In addition, the brand will have information for physicians across multiple screens, and may even have an interface for physicians and patients to share information together in the exam room. These screens need to talk, learn and share with each other in preparation for the next visit.

But to do this we need a singular identity and sign-on for each of our participants, we need a system that can associate that identity with all forms of content and past/present/future interactions across multiple properties. We also need the tools that can collect and manage the data generated by all of the unique interactions between these personal and digital constituents and can enable the tools that we need to better understand daily interactions. And we need it for individual brands.

Not some massive infrastructure project that takes years to get off the ground and is a one size fits all solution. Not some custom work for hire solution that requires precise configuration for even a chance at success.

We need something that is implementable and intuitive, that powers engagement and understanding. We need something so powerful and scalable, yet so easy to implement and manage.

We need an approachable cloud.

A cloud that comes out of the box and is ready to deploy with little configuration, a cloud that can be plugged into properties both old and new, a cloud that can work with hundreds of APIs and plugins but can be deployed by a single brand.

The cost of creating something like this in house can be a daunting expense of resources, time and money. Many of the enterprise solutions are rather complex to set up, require significant investment to maintain, and are not easily deployed or integrated with existing client data. And on top of that, none of them understood even the basics of compliance let alone something as complex as healthcare’s HIPAA regulations.

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.

(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)

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:

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.

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. 

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

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.

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.