wouldn't this be cliche biting the hand that feeds? Seems to me motorola owes some of its recent success (or just the fact its remained in business, and not become another nokia) to its android devices? does google not have any recourse if moto decides to pull this crap? i guess worse thing google could do is leave motorola with the open source bits, and not provide any support/co-branding or whatever goes along with the current arrangement.
im running droidx/gingerbread and get almost 48hrs battery, and NEVER have a reboot. your a bad user. best to stick with apple and youll be protected by the walls around their garden.
You failed to reasonably address any of jsz0's points (using a weak anecdote as your only evidence). You then proceed to unnecessarily use all caps to accentuate 'never' and go on to say jsz0 is a 'bad user' which is meaningless. You end with a whiny snarky remark about Apple's walled gardens. In addition to all this you typed I'm, you're, and you'll incorrectly while not capitalizing any of your sentences.
You seem to be new here, but please refrain from commenting until you can match the quality of the others you see on the site. Your comment in its current state adds nothing to the discussion and is poorly written.
it really depends on the application/site. 2mb of JS is not much when you look at some of the more advanced web apps. also keep in mind this is progressively loaded. initial page request with this design pattern will be minimal.
It's slower, right? I remember some years ago it would take like 5 seconds on this kind of big web app to show me the newer version of the file I just changed.
You technically can compile ASP pages on the fly in production but it's bad practice, just like making changes directly to production is bad practice. The whole blog post is pretty much a great write up of how not to manage a website.
Was I incorrect that he was talking about small sites, or do people just believe that every site regardless of size should use a deploy script and the other trappings of large application/high volume production development? Because the latter is silly.
Doing a tested change and then a pushing to production is a 4 command overhead using git as lazily as possible with maybe an additional 5 minutes spent during initial project setup. You're doing the same coding work, you're just helping to ensure it's not going to create any completely useless work spent undoing mistakes. It's an ounce of prevention, pound of cure argument in my mind.
It's really not that clear cut. To do what you propose, you either have to set up an identical staging environment, or you have to set up a local environment that mimics (and stays in sync with!) the production environment. For a tiny site that sees <100 people a day, where the potential damage of a mistake is absurdly low (so what if 5 people see the broken version while you make corrections?) it's not necessarily worth the additional hassle.
This all depends on what kind of site it is, of course, but in the context of what he's saying, it makes sense.
i like how you bash the source, then proceed to enlighten us with your "stack". dont worry, im all for your stack just as much the source... just chill with the bashiness
we are talking VM's... not multiboot. you can have many VMs(applications) open at once time. those application have access to the shared disk and other resources. have you seen parallels? the user would not change workflow _at all_. they dont know their app is now in a VM.
Again, saved state. In my work projects often go on hold for months or years - I might need to come back to a project and pick up where I left off even though in the interim I replaced my primary computer, browser, and production software.
And in my writing side projects, I may leave a project for several months. So that's where I realized the value of VM's - the one's I use have survived an upgrade from XP to 7 with the same open windows and without any software reinstallation (and of course without any recreation of bookmarks). I'll add that they are also descendents of previous virtual machines used for the same purpose but different projects. It is more efficient from a workflow perspective to have six copies of Open Office each pointing to the relevant context than to reconfigure one copy each time the context switches.
To put it another way, the way in which one develops software projects from a custom starting point and the way in which references persist across IDE sessions during a project due to saved state are not unique to software development. They are indicators of the features which facilitate efficient project execution timelines.
