Wednesday, December 28, 2011

thought for making development-to-production code pushes less prone to bit rot

you know that familiar problem where your development environment isn't in sync with the production servers? you upgrade the software so you can test new features, you push to production, and HOLY SHIT the site breaks because you weren't developing on the same platform. that is, if you aren't already doing the fucking upgrade polka just trying to get the newer software shoehorned into the old-ass legacy PROD machine. here's a potential fix.

you keep your codebase locked to your system configuration. if a dev server's software changes (or really, if anything on the system changes), you take a snapshot and you force the code to be tagged or whatever to the new snapshot. in this way the code is always in line with any given system configuration so you know what code works with what system configuration.

also, you always keep a system that matches your production machine. your HEAD development tree may be a wild jungle but only code you commit to the branch that is the same as the production machine can be tested, and only the development machine with the exact same system configuration as the production machine can test the code. so you will have your HEAD dev system and your PROD dev system, and the PROD dev system will mirror the PROD machine, not the other way around. you can call this "QC"/"QA" if you want but dev systems usually have local edits and don't do normal deployments and other bullshit bit rot creep.

so on the HEAD machine developers can test whatever the fuck they want, but until it works on the PROD dev machine it can't be deployed to PROD. this will also force you to actually do unit testing and other fun shit to prove the PROD dev code works as expected before you can deploy it. yay!

Wednesday, December 21, 2011

FUCK ANDROID

AAARRRGHHH.

I need to make a phone call to a local business right now. I can't, because every time I dial the number and press 'Dial' the "3G Data" option window pops up. It simply will not dial the number. I have put up with your shit, Android, and i'm done with it.

This isn't the first problem you've had. Your apps seem to crash daily, or one app sucks up "35% CPU" and makes every other app lag like my grandmother in molasses. Stock apps like the Browser and Maps can bring the whole thing to it's knees. And in these weird states, on the few times I actually receive a phone call, I can't swipe to answer it because the UI is too lagged. Let's not even talk about the native text messaging, which is not only the laggiest SMS i've ever used but the first phone to actually fail to send SMS's on a regular basis.

Google's apps in particular seem to suck. Google Voice takes about 30 seconds just to refresh the text messages once I open the app. Maps has weird bugs so that if I lock the screen while viewing the map, the map freezes and I have to kill it and restart it. Randomly the whole device will just appear sluggish even if I haven't been using it. And some apps become impossible to uninstall, becoming nag-ware for registration or payment.

A PHONE SHOULD BE A PHONE. All I wanted was to have GPS, Maps and Browsing built into my phone, and maybe a nice camera (but years later apparently Sony is the only company capable of putting a decent camera in a phone). But that was too much for you, Android. You had to be fancy. And now i'm throwing you away.

Nobody should be making Web Apps

let's face it. you're doing it wrong. it's not your fault; the rest of the world told you it was okay to try to emulate every aspect of a normal native application, but in a web browser. don't fret, because i'm about to explain why everything you do is wrong and how you can fix it. but first let me ask you a question.

what do you want to accomplish?

A. producing a markup-driven portable readable user agent-independent interpreted document to present information to a user?

B. letting a user interact with a custom application with which you provide services and solutions for some problem they have for which they don't have a tool to solve it?




if it's A you chose the correct platform. a web browser is designed to retrieve, present and traverse information through a vast network of resources. it has the flexibility, speed and low cost of resources to let you pull tons of content quickly and easily. after all, we all have at least a gigabyte of RAM. you should be able to browse hundreds of pages and never max out that amount of RAM - right?

if it's B this is the wrong choice, and for a simple reason: a browser is not an application platform. it was never designed to provide for you all the tools you need to support the myriad of applications' needs. imagine all the components of an operating system and what it provides to allow simple applications to do simple things. now consider a web browser and what it provides. starting to get the picture? here's a simple comparison: an operating system is a fortune 500 company and a web browser is a guy with a lemonade stand. no matter how many 'features' he can sell you, the super low-calorie healthy organic sweetener, the water sourced from natural local clean purified streams, whatever: it's still lemonade.




technical reasons why web apps are dumb:
  1. in a very literal sense the browser is becoming Frankenstein. slow, kludgy, gigantic, unstable, a security risk.
  2. verifying if my credit card number was typed in correctly is fine, but javascript should never run actual applications or libraries.
  3. applications that can interact with the local machine natively can do a wide array of things limited only by your own security policies and the extent of your hardware and installed libraries (which can be bundled with apps). web apps have to have the right browser installed, the right version, and compete with whatever other crap is slowly churning away, restricted by hacked-on browser security policies designed to keep your browser from hurting you.
  4. web applications are not only sensitive to the user's browser & network connection, they require your server backend to provide most of the computation resources. now not only can a user not rely on the application as much, you have to put up the cost of their cpu & network time, which is much more difficult than it is expensive when you really start getting users.
  5. the user doesn't really give a shit how their magical box provides them what they want. they just want it immediately and forever and free. so you're not really tied to using the web as long as you can provide them the same experience or better.
  6. seriously - Web Sockets?! are you people fucking insane? why not a Web Virtual Memory Manager or Web Filesystems? or how about WebDirectX? ..... oh. nevermind. *headdesk* i can't wait for Real-Time Web Pages.




i know what you're saying: what the hell else am i supposed to do? make native apps? i would compare the smartphone mobile app market to the desktop app market but the truth is it's ridiculously easier to bring in customers for mobile apps. and yes it's probably ten times easier building web apps with all the fancy friendly frameworks that can be tied together to push out new complete tools in hours instead of days or weeks. but that's also no excuse because it's all just code; we could build easy frameworks for native or mobile apps too. what is the alternative? is there one?

i don't think there is. Yet. you see, where the web browser fails us we have an opportunity to create a new kind of application. something that's dynamic and ubiquitous yet conforms to standards. something easy to deploy, cross-platform and portable. something using tools and libraries implemented in fast native code. something with an intuitive interface that exposes a universal "store front" to download or buy applications to suit our needs. something local AND scalable. sounds like a pipe dream.

maybe we can't have everything. but i see pieces of this idea in different places. when i look at Steam i see most of what's necessary for a store for applications, a content delivery system, a (mostly) secure user authentication mechanism. if it were possible to take the simplicity of Python (but you know, without the annoying parts) and make it reeeeallly cross-platform by design, then produce simple frameworks to speed up building of new complete tools.




the last thing you'd need is a way to make it sexy enough for everyone to pick up and start using. there's the difficult part. it seems to me that the competition of a few major players and the evolution of standards for new web technology is what led the arms race to bring "web apps" as the most ubiquitous computing platform for user interaction (next to mobile apps). that and the trendy, almost generation-specific explosion of investment of time in javascript-based frameworks led everyone to just build web apps by default. the new solution has to be needed for something for anyone to pick it up. you could start it as a browser pet project, but it seems uncertain whether other browsers would pick up the technology or wait it out.

this is where my sleep deprivation and the hour's worth of work i need to put in makes me ramble more than usual. my main point here is: make it easy, make it convenient, and make it somehow better than what we've had before. the end goal is of course, to stop creating bloated-ass crazy insecure web browsers that threaten our financial and personal lives and instead make stable, powerful applications which don't need a specific kind of browser or class of machine to run (necessarily).

bottom line: browsers aren't an operating system and the world wide web is not the internet. the former merely is part of the latter.




(disclaimer: i don't write web apps)