I'm amazed at how much this has knocked me on my arse.
I first attempted to redo the README for a service I've just open-sourced, before realising Github is down.
Then, I attempted to fix the company CI server (OOM errors because of Carrierwave needing more than 500MB of memory to run 1 spec in, for some unknown reason), which failed because it couldn't check out the code.
After giving up on that, I attempted to install Graphite to a company server, where I hit another roadblock because the downloads are hosted on Github, and so I had to use Launchpad, which I had an allergic reaction to.
Also, when I was shelling into the server, oh-my-zsh failed to update because, you guessed it, Github was down.
Still, shouts to the ops team in the trenches, we're rooting for you.
Your company runs its source revisions through Github without a backup solution? Do you really put all your eggs in a basket you have no control over?
I know that in theory a cloud solution should have a higher uptime than an amateuristic set up private server, but cloud solutions have a certain complexity and coherence that make them very vulnerable to these kinds of 'full failures' where nothing is in your control.
Maybe you should take this time to learn from this, and analyze what you could do to reduce the impact of this failure. For example, you could research what it would take for your company to move to another Git provider, perhaps even on your own server or a VM slice at some cloud provider.
I'm not saying you should drop github, because obviously they have great service, but be realistic about cloud service.
Cloud service is like RAID: it is not a backup.
The way RAID is nice for recovering from errors without downtime, there is a chance something bigger happens and you still lose your data cloud is nice for offering scalability and availability but there's a chance everything goes down and you still can't run your operations.
* Git is decentralised, if Github drops off the face of the earth, it will take the two of us about half an hour to fix it as we each have a copy of the codebase on our laptops.
* If I wanted the build server to point to our internal git mirror, I would configure it to point to our internal code mirror, but I want it to build off of Github webhooks.
* The "eggs in the basket" analogy is probably best saved for a situation where I'm dependant on a cloud service, such as Twilio.
* I would expect an amateuristic private server to have better uptime than a monolithic service such as Github because there are a lot less moving parts, and in our case, a lot less people doing things with it.
* The "company impact" of Github going down is next to nil. It's one o'clock in the morning on a Sunday, I'm eating string cheese, and I feel like being productive. The company is not paying me for this, and have encountered zero losses from it. We have a very simple mirror which we can use to push code to production if Github goes down, which we have never actually had to use.
Personally, I find the "keep a torch in every corner of every room because for 15 minutes last year the power was out" attitude to life is a bit over-rated, and you're planning for an edge case. I'd much rather remember where the torch is and learn to walk in the dark.
Add up your downtime over a three year period by relying on Git (or gmail, or AWS) versus the cost of trying to engineer some local-backup system, and the downtime associated with that going awry.
Outages happens - as long as we're talking hours a year, pretty much everyone but life-safety systems, critical infrastructure, and payment/high-traffic commerce sites are probably better off just letting third-party cloud vendors manage their systems. Take the downtime and relax.
(Now, if downtime consistently gets into the 10s of hours/year, it's time to look for a new cloud provider. )
You make a very good point, but it took me about three minutes to build a git mirror which we can push/pull to, can re-configure CI to if we need to, and can be used to run a full deploy from on the company VPS server.
* Create an unprivileged account & set a password that you don't need to remember -> sudo adduser git
* Add your public key from your laptop to the unprivileged user's authorized_keys file -> sudo su git; cd ~; mkdir .ssh; vim authorized_keys - then copy and paste your id_rsa.pub to that file
* Repeat that for all public keys on your engineering team
* In git's home directory, git init --bare <name of repo>.git
* On your local machine, git remote add doomsday git@<DOOMSDAY SERVER HOSTNAME>:<NAME OF REPO FOLDER>.git
* git push doomsday --all
* On colleague's box, git clone git@<DOOMSDAY SERVER HOSTNAME>:<NAME OF REPO>.git
Let me know if there is a better way of doing this, or if it's monumentally screwed somehow.
Yup. Github going down barely breaks my stride, but for a real production outage (e.g. Heroku going down), I pour myself a tall glass of scotch and thank my lucky stars I'm not the one who has to scramble around tailing logs and restarting servers. I'm pretty sure their ops team is better at this than I am anyway.
It's not about downtimes and outages. It's incomprehensible to me how lax businesses are with their backups, especially business where their clients data is everything. Yes, the brave new world of the cloud seems tantalizing, but even there, data can and will be lost. Don't just use only one way / provider / service / mechanism for backing up your data.
A tape / lto backup system doesn't cost the world. Yes, it introduces overhead and maintenance, but I'd rather be safe than sorry.
At my place of work we currently use a lot of virtual servers, hosted by external providers. We use their backup and snapshot mechanisms. But we also pull all data to our local back up server. From there we backup to tape on a daily basis.
I do have backups of all my (relevant) GH repos since that's just a "git pull" away and can be automated nicely. But I'd probably be out of luck running my regular CI-process with github down or do a deployment. Both rely on having a public-facing git server - having a backup does not imply that I have a full git server running. I could set one up and administer it, but it's just too much effort given GH uptime.
I doubt it. (Assuming by 2 digits you mean < 99.0%, ie that they don't have "two nines" (though I guess two nines could even be 98.5 with rounding)).
1% downtime is over three days. They've had some big outages, but I think this may be their longest of the year and it was a < 6 hours. They could have one of those every month and still only have 72 hours of downtime, which is 99.18%.
I agree with you but one thing: you don't have to build anything locally. Just pushing to bitbucket as backup would have done it. It does not have to be a locally hosted solution.
I agree with the "Don't build anything for twitter" motto (and it would look good on a t-shirt), but part of me wonders if twitter could get by charging 25 cents a token past 100k, so developing apps is still possible, and twitter still gets its slice of the pie.
Although, it still kills the advertising cash cow.
I've always wondered why Twitter doesn't do something like this. Why wouldn't they change their rules to something like: Once you have more than 100k users you pay us 5-10% of every copy of your software sold. If your app's free then you don't pay anything.
I'm pretty sure developers would agree to something like this and Twitter could get some extra money that they're not getting right now.
As amazing as writing an application relying on a UIWebView for its core functionality, it still crashes when you scroll for long periods of time, and instacrashes when you attempt to look at your likes.
I am admittedly on v.3.0.x, but the version previous behaved the same way, so I have little hope for future versions.
I must admit, the Tumblr app is one of the few apps that make me want to throw my phone against a brick wall.
I'm the developer of Tumblr for iPhone and sorry to hear this. I know that web views have their drawbacks and we're working hard to make the app faster and more stable in every way.
While we have your ear: just wondering what the thought process behind the latest redesign is? Yes it's really~pretty...but the functionalities that made the older app attractive are mostly gone.
- cant long press to copy a tumblr link (heaven forbid I'd like to share a link OUTSIDE of the app
- cant post YouTube urls in video post
- reblogs won't let you delete prior comments by others (sometimes you have to clean up cluttered reblogs)
- you took away options to open in safari in many instances as well.
These were not intentional omissions. 3.0 was a complete rewrite and there are still many features that we know we need to add in order to be on par with the web experience.
I strongly encourage any users with feedback or feature requests to hit up my ask box: http://blog.bryanirace.com/ask. We really are listening and plan on providing the best mobile Tumblr experience we possibly can.
Edit: Worth noting that we added post sharing options in 3.1 (long press on the 'Like' button).
Eh, it's not the only thing I find wrong with Tumblr, and I'm yet to try out your latest release (stepped on debit card, broke it, cancelled it, iTunes charge failed, no upgrade for me)
Please try going native, the performance increase would be in the order of magnitudes.
I'm not the only one but it's a very small team at the moment. We have ambitious goals that we're aggressively working towards though.
Tumblr content can be quite diverse and often contains arbitrary user-inputted HTML, numerous inline images, etc. It's non-trivial to render but as I mentioned, we're working hard to provide an even better mobile experience.
Yup. The latest versions of the app has actually driven me away from tumblr. It is un-intuitive, clunky, and poorly thought out. I'm not the only one who feels this way too.
I'm an ex-intern of Iron.io (ply me with enough alcohol and I'll tell you about it), and I can roughly explain IronWorker: background processing without servers, with a scheduler on top.
I wouldn't call it a 'negative value add' because it means you don't have to babysit a server somewhere, assuming you want to add scheduling onto a Twilio action (call/SMS).
If you took Iron.io out of the equation, how would you schedule the Twilio call? I assume you mean via cron, which is all well and good if you want another server/script to babysit.
That said, I haven't used anything from Iron.io since I've left, and I've written scripts which use a loop, sleep and two if statements to 'schedule' a Twilio call.
That Sinatra application can be run locally. From what I have gathered from the article, the Sinatra application is a pretty form for putting your phone number in, nothing more, Twilio calls Iron.io directly.
Where are you located? I'd love to beta this and provide feedback? Would you be interested in this... I am a product manager, IT background and other things... I alos have an amazing Designer I could hook you up with...
>> This is intended to be constructive criticism, though you may find it harsh.
Any criticism is good right about now
It's very much a competitor to GMail, in that it's essentially GMail with some filtering and IMAP magic on top
To start with, my problem that I am attempting to solve is notifications for things I'm not interested in in the middle of the day, which I have attempted to solve with notifications + funnel
The distinctive advantage is the ability to modify when email is sent to you, plus the ability to filter different types of email (transactional, newsletter, human beings)
You're right on the unprofessional copy, I'm sorry, and the punctuation mistakes are simply a flaw in my English (It is my first language, there is no excuse)
I spent 3 months on the backend making sure it receives email perfectly, and securely, and I could not find a mail server written in Ruby which I could modify and add features like Funnel to
It supports IMAP, IMAP is the primary method which devices will retrieve email with (ActiveSync is patented by Microsoft, who would like licensing fees)
It will also support Android, as in, the native mail app on Android, I am just prioritising iOS first because it avoids competition with native GMail, which as one person, is nigh on impossible
Yes, it's primarily geared towards iOS devices for now, because I don't think I can compete with the GMail + Android paring yet
Thank you very much for the criticism, I'll do some changes now
> I spent 3 months on the backend making sure it receives email perfectly, and securely, and I could not find a mail server written in Ruby which I could modify and add features like Funnel to
The Sup mail client[1] went through a phase trying to handle IMAP directly, but the consensus was that it was simply too awful. It did yield some colorful code[2], but the fallout was that most people relied on offlineimap[3] to get their mail successfully.
$20 per month, per user seems a little high when compared to Gmail which is either free (personal) or $5/month (business). The fact that Google is able to charge for email is partially due to the fact that they offered it for free for so long and got so many people to like the experience that it created a lot of demand in the workplace for it - I think you really need a way to let people experience your application for free if you want any shot at enticing people to pay $20/month for it.
There may be some subset of people willing to pay $20/month for ultra-configurable filtering, but I'm not really sure how big that market is, and I doubt it will help you break into larger organizations.
You should be able to fix the readability of this without hiring a designer. Not that you shouldn't hire a designer, but you shouldn't wait to fix it before you hire one either. Since email is all about text, if it looks unreadable that's going to be a big turn-off. Read at least the next paragraph of my post!
To start, I would reduce the font sizes on your header-type items somewhat. It's clear that you're using large fonts and bold to emphasize key information (which is the right idea), but a heuristic I've found is that if you're using bold, your font doesn't need to be as big, or if you're using a large size, you may not need to be bold. When you do both, it's like an assault on the eyes, which you don't need here. Doing this alone would make your app like 75% better (note: I made that number up entirely and don't know very much about your app.)
Next, you could tone down the reds (I would change the hard red #F00 color to the softer pink-ish color, and then reduce the pinkish color further), and exchange the black on white for something else. For your icons, you could experiment with grays (I like to start with #333 and then go up or down), so they're less overwhelming.
Finally, add some labels for your icons. Remember how you made your fonts smaller before? Well that applies to these labels. They should be contrasty so you can read them, but otherwise it's fine if they're subtle.
A couple of minor points about your website: the proper name of your competitor is Gmail, not GMail. You should add more spacing between your icons and the text (it feels crowded currently.) Also, your circle arrow jobs are getting cut off at the bottom.
Finally part ii: don't forget to steal from others. Obviously I don't mean blatantly stealing a design, but just check out what other sites do. To do this effectively, you have to pick a particular thing and examine it closely. So for example, if you want to figure out how to do headers, go to other sites and see what they do to give emphasis to things without being overwhelming.
The font is Segoe UI, I did that screenshot before I bought Proxima Nova, so the font will become Proxima Nova (I may Instapaper this and give you a bazillion settings for it)
As for the icons, they are a very tricky subject, I intended to create symbols for major features such as Funnel and Triage and have common icons for everything else, but it seems I've failed there
Typekit gets you Proxima Nova as part of their package among others fonts. It's not bad, but for something like email, it may be helpful to use the standard stack of fonts.
My app sends emails (not a competitor). The interface uses proxima nova, but the email rendering is generally in an iframe with default sans-serif or serif font-faces.
If you use sans-serif as the first font-face that will default to Helvetica on Macs and Arial on Windows.
I generally don't like toolbars with lots of icons that don't have labels. Google's web properties have been moving in this direction and I find myself having to click buttons to figure out what they do.
I first attempted to redo the README for a service I've just open-sourced, before realising Github is down.
Then, I attempted to fix the company CI server (OOM errors because of Carrierwave needing more than 500MB of memory to run 1 spec in, for some unknown reason), which failed because it couldn't check out the code.
After giving up on that, I attempted to install Graphite to a company server, where I hit another roadblock because the downloads are hosted on Github, and so I had to use Launchpad, which I had an allergic reaction to.
Also, when I was shelling into the server, oh-my-zsh failed to update because, you guessed it, Github was down.
Still, shouts to the ops team in the trenches, we're rooting for you.