Enterprise software sucks

Software is hard, but when you are trying to make a “one solution fits all” you create whole set of problems including shoehorned workflows, horrifically counterproductive forms, maintainability and migration problems. And before we forget dependency on the Internet Explorer 6. We must give them credit for this all can be the result of customisation, but from what I know about SAP, Oracle etc, this is a cross-the-board issue for them.

Problem #1: Problem is single piece of software being used within one organisation that needs to meet the requirements of different teams and a multitude of different end users.

Problem #2: The users and the buyers are not the same people.

Problem #3: Integrations are inherently complex due to the nature of trying to tie together heterogeneous applications with different data models, granularity, cardinality, semantics and protocols.

Problem #4: Too many features, most of the software vendors might say yes to all your RFQ questions, but when you actually start implementing the software you find that its not as simple as it sounded.

Problem #5: Design decisions by “managers”

We at @sourceeasy are trying to solve a lot of these problems for the manfufacturing industry. More posts to follow on the same theme.

Amazon Cloudfront or S3

Amazon CloudFront is Content Delivery Network (CDN), that takes its data from S3. What actually does is replicate the S3 data in different locations, so that…

When end users request an object using this domain name, they are automatically routed to the nearest edge location for high performance delivery of your content. (Amazon)

That’s the main difference, and you take advantage of it when your user base is “spread around the world”. So…

If your user base is localized, you won’t see too much difference working with S3 or CloudFront (but you have to choose the right location for your S3 bucket: US, EU, APAC). If your user base is spread, CloudFront should be a better option. Another difference is that CloudFront allows you to set different domain aliases for your CloudFront distribution:

You can have for example d1.mystatics.com, d2.mystatics.com and d3.mystatics.com pointing to the same CloudFront distribution, allowing parallel downloads. (Google)

via so

It’s not piracy, it’s you

Why do we pirate music, software and television and movies? It’s not all about the money, mostly. There is/was a french project Pourquoi je pirate where random strangers were asked why do they pirate, I present you few of my fav responses. Please see that these responses are a direct translation from french.

  • Why not?
  • For episodes of series as they are released, without advertisement.
  • because it is more environmentally friendly than creating a CD, DVD, BLU-RAY
  • Because the music I listen to are not for sale in my country
  • I always try my clothes before buying.
  • Because Megaupload closed (revenge!)
  • To form an opinion on music, film, series. To find out what a friend talking, critical in any magazine. To get your hands on a totally obscure foreign film. To find musicians who do not fit into the mold enough to be known by the radio or TV (which I do not use elsewhere, this mold does not interest me). To build me an artistic culture without spending fortune would be necessary according to the law, if
  • Because without pirates, some artists will drown in the sea
  • Because having more than 1 TB of movies that makes me cool by not looking half.
  • Because cinema is too expensive, you have to run after work for an hour, it’s not comfortable, it’s ugly as a place, the sound is too loud, you have to pay pubs and trailers weak (but I still spent an ebook in the public domain to read a book on my phone for those times). Because ultimately, the movie sucked, I would have done better to download warm home. This is not valid for small arthouse theaters.
  • Because a budget is not infinitely expandable and even if I agree to give 20 to 30 € / month (which makes us all the same € 360 / year) to buy an album, I’m not willing to pay I look at everything and anything I listen to. The question is, ignoring buyer or pirate grown? Personally, I have made my choice.
  • Because intellectual property is an absurd notion.
People are very selective about, the content they want to consume and current distribution channels are unfortunately broken. I mean Movie halls, DVD releases etc are all broken. A recent experiment by an standup comedian Louis C.K. sold tickets on his website. He said the following, btw, he sold within 40 minutes.
By selling the tickets exclusively on my site, I’ve cut the ticket charges way down and absorbed them into the ticket price. To buy a ticket, you join NOTHING. Just use your credit card and buy the damn thing. opt in to the email list if you want, and you’ll only get emails from me.Also, you’ll see that if you try to sell the ticket anywhere for anything above the original price, we have the right to cancel your ticket (and refund your money) this is something I intend to enforce. There are some other rules you may find annoying but they are meant to prevent someone who has no intention of seeing the show from buying the ticket and just flipping it for twice the price from a thousand miles away.
The consumer wants control. They want freedom. Give people what they want, when they want it, in the form they want it in, at a reasonable price, and they’ll more likely pay for it rather than steal it.

Twelve-Factor Application

If you’re building a web application, you should design it as a Twelve-Factor Application. A Twelve-Factor Application follows twelve principles:
  1. The entire application’s code is stored in a single revision control repository. If you have multiple repositories for different parts of the software, you should consider them to be separate applications that treat each other as services. If you have multiple applications in a single repository, you should factor out whatever they both use as a library they both depend on and then split them into two codebases.

    For your revision control system, you will probably want to use git, because it’s the most featureful and most popular.

  2. All your dependencies should be explicitly declared. In Ruby you can do this with a Gemfile, in Python with requirements.txt, etc. Locally, you should use a tool like bundler or virtualenv to isolate your environment to make sure you aren’t using any undeclared dependencies.

  3. All configuration values should be stored as environment variables. This includes anything you’d be afraid of making public, like passwords or secret keys, as well as anything that might be different from deploy to deploy, including the locations of databases or the administrator email address.

  4. All backing services (like databases or in-memory caches) are treated as services. No distinction is made between local and third-party services; they’re all accessed over the network.

  5. Code is deployed in three separate stages: build (in which the software is compiled and built), release (in which it’s combined with the configuration environment and put onto the appropriate servers), and run (in which it’s executed). These stages should be completely isolated – the server can’t change its configuration at runtime, since the release stage has already been passed. And the release process can’t edit the software, since the build stage has already passed.

  6. The application should execute as a series of stateless processes that share nothing – any process should be able to be killed at any time. This means any state needs to be stored in one of the backing services.

  7. The application should be completely self-contained and contact the outside world through an IP port (designated by the $PORT environment variable). It shouldn’t be expecting to live inside some sort of larger process.

  8. The application should be made up of various process types and be able to scale by starting more instances of these process types. For example, if there’s a lot of web traffic, you should be able to handle it by starting more instances of the web process type.

  9. Processes should be disposable – you should be able to start them and stop them at a moment’s notice, without any harm.

  10. The gap between development and production should be kept small – the same backing services, dependencies, and team should be used in both places. Development is just another deploy of the application with a slightly different config.

  11. Logs are just a stream of events written unbuffered to stdout. It’s not the application’s job to make sure they get to the right place; that’s the job of the infrastructure.

  12. Administration tasks should be run as one-off processes.