Forgot your password?

Comment: Re:"not my job" - It is *Microsoft's* job (Score 2) 426

Object.observe() - new built-in mechanism for getting change events when a plain javascript object changes (new property, deleted property, changed property, deleted). Chrome 36 is the first browser to get it, but it is an established part of the html5 standard.

Greatly simplifies a lot of the work the model layers have to do, and eventually means that many frameworks will over time get rid of their setter/getter mechanisms and all the weight they have.

Comment: Re:"not my job" - It is *Microsoft's* job (Score 2) 426

Yes, CSS tends to be my biggest issue. Some aspects of IE events are still wrong. How IE decided that the "unresponsive script" dialog should come up was horrid, constantly causing issues in sproutcore/ember apps.

Some of these things are better. They are getting closer to the standards. My take remains: it is their job to finish that, not my job to meet them half way anymore. If my stuff works on IE, great, but I'm not and will never go out of my way to make it work anymore. I personally will never actually run my personal apps in IE, ever. I have 1 Windows7 box left in the house (and 2 XP boxes are now Ubuntu); that box got Chrome on it as the very first thing.

(yes, professionally others in my company are doing that with our primary product. I professionally support that decision, though all I am doing as part of that effort is code-reviewing. These opinions are for my own personal projects independent of all of that.)

A lot of all of this is what and where is your market. A big corporation targeting big corporations is free to spend that kind of money. But to do that, M$ needs to stop acting like they want to attract 'developers' as the original article implied. M$ does that by attracting execs and having such decisions forced on the developers from on high. Just as they've done in so many other things.

A small development shop targeting a more general user has no need to worry about IE compatibility as their primary concern. Wait for the money to actually be there (or at least be promised) before you invest in that type of thing.

Comment: Re:"not my job" - It is *Microsoft's* job (Score 4, Insightful) 426

Microsoft's ability to control de facto standards is long gone. When Netscape collapsed but Firefox was too immature, they had control. The Standards bodies worked to make html4 and Microsoft could happily ignore all of that, create their own broken implementation of CSS (this is worse than their jscript problems) and happily make everybody else play along.

Now what they want is that same control back, but as Disney once said, "That ship has sailed." This idea of pushing to developers to create specialized webapps that are IE compatible betrays the fact that they have not been in control for years now.

I am not going to code to IE compatibility; I'm not going to break my application by trying to get it passed IE's continually broken CSS. I code to the standards because the standards are the greatest likelihood that my application, if converted to a full-out mobile app via Cordova, or converted to a desktop-app via Adobe Air, will continue to function without change. My stuff mostly works in IE. It is up to IE to finish their job and fix their CSS and their event model and all of that stuff. I'll come part-way by using certain libraries that others are willing to address compatibility issues (jquery, for example) but no closer.

Comment: "not my job" - It is *Microsoft's* job (Score 5, Insightful) 426

As much as Enterprise customers like to push the "it has to work on IE" crap (because they're usually working with lazy IT departments or legacy applications written by people with less interest in standards compliance than me), in reality that shouldn't be my job for writing a web application. I code to the standards or I use libraries and frameworks that code to the standards. These work in Firefox, Safari, and Chrome with minimal modification (assuming I'm not using a cutting-edge new feature like web audio, notifications, or O.o()) and impressive consistency.

They never work in IE without modification.

That's not my fault. That will never be my fault.

If you want to court developers, you go out there with IE, pick apps that have not gotten IE-fixing mods, and YOU (Micro$oft) fix the browser to the standards-compliant web applications already out there.

I'm sick of and done with working around your messes for the last 15 years.

Comment: Re: Your Results Will Vary (Score 1) 241

by acroyear (#47491893) Attached to: Math, Programming, and Language Learning

When a user interface is in, say, HTML5/DOM, one needs to know a lot about controlling how often the browser reloads the page or a portion of it, how much CSS is "too much" before the page rendering is slower than tolerable, how to control a loop to minimize server calls and DOM redraws, and much more. Similarly, a lot of UI is search optimization, deciding how much power of the search goes into the server/db and how much in the UI, then how to find and highlight the search results - all of these are complex processes that can be painfully slow or dramatically fast, but only if you know what bottlenecks to expect.

Anybody can draw a UI on a piece of paper and bullcrap the thing up in jquery-ui or xcode. Making a UI that is functional amidst constantly changing requirements involving ever increasing quantities of data is much harder. Writing components or maintaining frameworks and understanding the decisions the framework designers made (so that you don't violate them, often with painful results in stability or performance, when using them or adding to them) is a huge part of REAL UI work. I have yet to meet a toolkit I didn't need to fix or amend to, in 20 years of UI work. I have yet, in any of those libraries/frameworks, to NOT have Big-O decisions to make when doing so in pieces involving components meant to handle large amounts of data like grids and graphs.

No, it doesn't happen every day. But it happens at least every project.

If you don't speak basic optimization rules/practices like O(N) vs O(log(N)) (and yes, that HAS come up more than once in my work in the last 5 years, nevermind the last 20 when I was doing more J2EE or MoM/Agents work), then I can't trust that you have any discipline to anything else. There's no point in even talking anymore if you can't speak what I consider to be a basic common CS vocabulary.

Yes, much of this is trust: the piece of paper that is a degree is something of a document of trust that you have had certain disciplines and experiences, things that I can't actually get directly from your work prior since I'm not actually allowed to ask to see your code in an interview or before-hand - that usually belongs to your former company.

We don't ask for higher maths because we expect you to use them; your 'experience' during your degree work is almost meaningless in-and-of itself. We ask for higher maths, and for the other aspects of a degree, because the degree is evidence of experience, motivation, and most importantly discipline.

And for many of the "I don't need maths blah blah blah a trade school is fine blah blah blah" posts on this thread (and this same thread every time this topic comes up, which is probably twice a year for the last 18 years I've been on /.), discipline is something I actually see sorely lacking in the comments.

Comment: Re: Your Results Will Vary (Score 5, Interesting) 241

by acroyear (#47486761) Attached to: Math, Programming, and Language Learning

In the end, I've always concluded the same, every year this topic comes up (it is just about annual here). I don't want you to know calculus because you'll actually use calculus on the job (though I have an O(N) vs O(log(N)) question on my interviews that you'd better be able to answer).

I want you to know/pass calculus because by the time you've worked that hard at that level of proofs, you've mastered *variable control*. In each level of math, you don't get out of the class having mastered it. You get out of the class having mastered the year that came before it. When you can pass calculus, you have *mastered* functions and analytic geometry (I hire for UI work). Passing those two the year before showed you mastered variable manipulation and proofs in Algebra 2 before it.

So no, you don't *need* calculus on the job, but you need everything below it, and the best proof that you've *mastered* them (not just taken them, but mastered them) is that you've passed a calculus class.

Comment: given we're nerds who know this stuff... (Score 1) 309

by acroyear (#47204097) Attached to: Was Turing Test Legitimately Beaten, Or Just Cleverly Tricked?

...why didn't /. just wait for the skeptical posts calling the original news articles bullshit in the first place?

Seriously, weeding out the garbage posts, 3/4ths of the comments were calling bullshit when they saw it, and 1/4th were making pointless references to Skynet and HAL.

Comment: Garbage (Score 3, Insightful) 432

by acroyear (#47191355) Attached to: Turing Test Passed

All it showed, like any other Turing Test, is the gullibility of the subjects.

1) "Ukrainian" speaking English
2) 13 years old

Right there you have set up an expectation in the audience of subjects for a limited vocabulary, no need for grammatical perfection, little need for slang, and a lack of education. Now add in "star wars and matrix" and you have reduced the topics of discussion even more to the ones the programmers know best.

This thing would never have answered a question of 'Why', it also was under no pressure to being able to create a pun, both of which are easy things any older and educated human could do.

Garbage test, garbage results.

As usual.

Comment: Martin Fowler's Refactoring (Score 1) 352

by acroyear (#47004687) Attached to: Ask Slashdot: What Should Every Programmer Read?

No, in spite of what some jackasses say, it isn't just rewriting for its own sake. It is improving the structure in standardized ways so that you can add your new features much more safely. In interviews, I prefer people can name some standard refactorings before I ask them the typical questions about design patterns.

Comment: Re:Oh please... (Score 1) 226

by acroyear (#46768605) Attached to: How 'DevOps' Is Killing the Developer

Please fuck off. No, really. Just fuck off.

I was typing in a fucking hurry. Its a fucking comments page of a fucking blog (one i have been fucking typing on since 19-fucking-98), not the fucking New York Times. if you want fucking capitalization to be fucking correct you can fucking type it up your fucking self because I don't give a fuck.

I presume I have expressed my attitude adequately enough? And capitalized New York Times correctly as well?

Comment: Re:It's just like when agile went hip... (Score 1) 226

by acroyear (#46766001) Attached to: How 'DevOps' Is Killing the Developer

Well I would counter that a DevOps team is needed even for customer-deployed or self-run cloud apps (where you're running the cloud in a data center instead of using services like NetApp or AWS). The jobs they do are useful there, in fact more so as staging DBs and environments for QA is harder when you're running all aspects of the cloud layer (though with customer-managed old-school desktop applications, QA is more responsible for their deployments, since testing installation instructions becomes part of their job).

But otherwise, yeah, treating DevOps like a panacea that will solve everything (thus necessitating hiring a DevOps manager who is 'smarter' than your lead architect, at possibly outrageous wages or options) is asking for failure.

Comment: Oh please... (Score 3, Insightful) 226

by acroyear (#46763471) Attached to: How 'DevOps' Is Killing the Developer

You don't force your brightest people to take on additional roles - that is the whole point of a devops team in the first place. Making developers argue about deployments and sending builds to QA and managing your GIT server and development and QA databases and managing your bug tracker is exactly what your developers should *not* be doing, especially if those scripts necessarily have to be in a different language than your application. Sure, your lead developers and architects work with the devops team to support them so they can in turn support you, but that's as far as the relationship goes.

The way we used to do it, where every senior architect is also responsible for all of those other functions (and has to take the time from his team members below him to help build all that out), is exactly how you stop architecting your software: your leads spend so much time trying to automate the drudgery they aren't improving the app.

They aren't improving the app because all of their brainpower is no longer focused on the *customers'* problems, but rather their own and their teams. That isn't a good use of their time. Hiring smart people who need to understand the application and its environment, but are good at scripting these other languages of automation, frees up your team leads to doing what they did before and do best: focus on the application and getting the team to produce the code that serves the customers' needs.

"The four building blocks of the universe are fire, water, gravel and vinyl." -- Dave Barry