Come on, we all know that the REAL reason devs prefer to code for iOS is because it's the only way we can convince the wife that we NEED that shiny overpriced MacBook Pro or MacBook Air.
The Wife Acceptance Factor.
> Then you look at a developer who instead of contacting IT and asking for support, had admin access and
> changed the
Why did the developer have admin access to a production server?
Us developers should only have access to test/qualification/staging, never to production. Unless we're the DevOp, in which case we're responsible for production and capable enough not to f**k it up.
It'd probably be easier to just buy a desktop PC and use that as the build server. If you need to store the results of builds permanently then just copy that over to a file share.
Want backup? Buy two of them.
That's better than having IT buy a production-capable server with all that that entails when a consumer-level box is fit for purpose.
> You are of course talking about window devs. Linux devs, fkiing write the software they use.
Ahem, so do decent "Windows" developers..
..nothing?
"The plot concerns a young woman biochemist, who discovers that a chemical extracted from an unusual strain of lichen (hence the title), can be used to retard the ageing process, enabling people to live to around 200–300 years. Wyndham speculates how society would deal with this prospect."
..and it works really well. For the iPad. That's because swiping your fingers horizontally is more natural than continually moving from the bottom to the top to scroll through a document.
+1
Between the best minds in the US being sucked up by the parasites in Wall Street and massive numbers increase in the number of law students (*) it really does look like the Empire is in the middle of its last greed-fuelled explosion, close to the point of spectacularly imploding in upon itself. Only the decay will likely be slower more insidious than that.
Time to move to Brazil.
(*) http://blueprintprep.com/lsatblog/law-school-admissions/big-law-we-have-a-problem/
> because all the selectable configurations in the Xbox made it so that
> you had to move your thumb off the jump button to do a grind
Welcome to the joys of Southpaw gaming.
This just sounds like another game where they're focussing on the little guys whilst ignoring the big tax avoiders.
Like this guy, who's a member of the House of Lords (comparable to the Senate, except half of the members get inn through birthright): http://www.guardian.co.uk/politics/2010/mar/04/lord-ashcroft-vat-conservative-polls
I always assumed so because the Office inter-op code I occasionally have to work with is COM-based mess, and I can't ever remember having issues with Office and
Examining Excel in ProcessExplorer proves that a silly assumption.
The article you posted is suffering from semantic leak. The words "layered" and "tiered" have many, subtly different meanings depending on who you're talking to. I, personally use a broad definition: a layer or tier says nothing about where the code is running.
The main benefit is that by having your state, interface and actions split up it becomes simple to change the way each of those are executed or handled. Data could be read directly from a database, with the actions running on a remote machine communicating with the client via RPC. Plus when separated it's generally easier to use codegen for each part targeting various platforms (ideal for implementing client-side validation!).
For LOB or data-driven applications (which I'm assuming is the standard use-case for Silverlight compare to JS/HTML) you would be advised to implement a service layer over your domain-entities. That gives you platform-level separation. Or at least it should, as that's kind of the whole point
With a service-layer in place, you have some kind of translation on the boundaries. For example you access your domain via a webservice, which serializes to XML, JSON, whatever, which is then reconstituted on the frontend.
These conversions should be totally automated and preferably nicely wrapped on the platforms supporting each layer.
Depending on your exact problem, you could even approach something such as Modal Driven Architecture. There you define an application as a model (usually UML), and then use that as input to your multiple, target-platform-specific compilers. This is particularly suitable to for CRUD systems: from one UML model you can generate a complete database, object model, winforms and web frontends. Though, to be honest, I'm not sure if there are many examples where the resulting interface can be described as "high quality". Oh, and from what I've seen the motivation for using such an architecture has been more to do with technical deficiencies of the modellers than any benefit over other methods. Though, as with everything, that's far from a rule. If your problem is easier to user-stand when it's modelled visually, and it's worth trading potential UI quality for it, then that's great.
It's also exactly the reason why you should choose a layered architecture, and preferably MVC/MVP or MVVM. They all make platform switching much easier as the frontend is a very think layer.
Silverlight in particular has a really nice MVVM framework called Caliburn (http://caliburn.codeplex.com/). If you've built your app using that, then it shouldn't be a huge amount of work to switch to html5/js for the frontend.
Hey, you might even be able to use a.net to js compiler to do the body of the work: http://jsc.sourceforge.net/
> the only reason why they can port office is because of
I'm pretty sure that Office is still written in native code.
Suggest you just sit there and wait till life gets easier.
