Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
DEAL: For $25 - Add A Second Phone Number To Your Smartphone for life! Use promo code SLASHDOT25. Also, Slashdot's Facebook page has a chat bot now. Message it for stories and more. Check out the new SourceForge HTML5 internet speed test! ×

Comment Re:Microsoft == dumbass (Score 1) 114

It seems it's not active throttling, just fallback to failsafe set of features; it's not the issue of specifically "Firefox+Linux", it's the general "Other".

Instead of feature detection, they sniff the UA string and upon failing to find a "supported browser" serve code for "unsupported" which is woefully unoptimal.

So, not evil, just lazy and incompetent.

Comment Self-incriminating password. (Score 1) 517

I wonder what about the self-incrimination rule if the text of the password itself is incriminating.

Imagine I'm being charged with possession of child porn, but my password is "TheCorpseIsBuriedBehindTheGarage".

Revealing it would be direct self-incrimination, regardless of the drive content, wouldn't it?

Comment Re: Lots of links to articles, phfft (Score 1) 232

Oh, the IDE can only go so far. It helps, but once you have the relevant logic spread over 20 or more files, no IDE will let you grasp it all.

I tried following what "smarter people" created before me. Preparing for every possible eventual expansion of the system - adding new business logic algorithms, new types of input data, new variants of output, dynamic switch of dataset and algorithm mid-execution, massive parallelism, with a lot of cross-thread communication and clever automatic scheduling of tasks. They had been mucking around with it for 3 years, making a system that was very elegant - and completely useless.

It appeared the underlying system requires everything to be single thread, running under RTOS, because critical operations were not being completed on time and race conditions resulting from the underlying system design abound. And the deadline was in half a year.

All that fancy work had to be scrapped and written from scratch, in a much simplified form only sparsely utilizing scraps of old logic. The whole fancy broad class structure with deep inheritance trees and clever class switch-over mechanism was scrapped, replaced by a couple of classes with inheritance through composition. The smart scheduling was at the core of race conditions; replacing it with two trivial, rigid lists of jobs (realtime, and background) solved the issue.

And it's now some 6 years. The system works fine. Extra business logic algorithm had to be added once, it didn't take more work than it would before. Cosmetic changes of logic happen every couple of months, and need to be applied in three places instead of former one. The idea of business algorithm switch-over on the run appeared to run afoul of safety regulations, the on-the-fly change leading to transitions not allowed by law. The dataset switching, performed maybe once a year, requires extra two minutes of work versus what it was originally. Its structure was only ever expanded, which meant business logic also only was expanded occasionally.

Meanwhile, an area that lay fallow during the first version - interaction with external systems - underwent massive expansions. The fancy structure wouldn't help one bit with that. The range of systems that came up, what they did and what they needed was so wildly varied there's no way any preconceived structure to accept them would ever stand a chance. The lack of such system appeared a blessing, because adding them was straightforward; wherever they had to slice right into heart of the business logic in a completely new way, there was no struggle to break through extra abstraction layers; a single if() operating on easily accessible superglobal replacing twenty new methods to access areas previously isolated from the rest.

The bottom line is that you can't foresee every way the system may be modified or expanded, and making the system extendable in a way you guessed would be common may very well appear both completely useless (the system will never be extended that way) and thoroughly detrimental to expansion in a way that is required. Keeping the system SIMPLE from moment one, and instead of trying to account for every possibility, only doing what it needs to do in the simplest way it can do, is a much better approach to making it easy to expand. And - surprisingly, maybe - makes debug easier too.

Comment Re:O'Reilly Posts One Weird Trick Every Programmer (Score 1) 232

It's often used for systems that are way too small to ever need the resulting complication. And when the system needs to be extended, it frequently appears what it needs to work with doesn't fit the current implementation in the least, and instead of writing a trivial interface, you are forced to massage the MVC engine/framework into fitting the new thing.

It's a decent system if you know majority of requirements a'priori, the system is big, and can only grow in well understood ways.

If the system is to grow a lot from a small root in ways you can't even roughly foresee, MVC feels like the smart way to make it flexible and easy to expand. Until you encounter requirements that are completely orthogonal to current design, say, deadline/realtime reply requirements, massive parallellization, making the system distributed, or porting to small embedded.

Adding an extra page with some report, or a summary, or shuffling a piece of UI into a different UI branch is nice and clean in MVC, and these are the typical expansion types you foresee. But if it's something like mentioned above, you're suddenly in for a long haul and a lot of heartbreak. Modifying stuff within a framework is nice. Modifying the framework engine - not quite so. And MVC frameworks tend to be heavyweight and very complex; in a lot of cases more complex than your application written on top of them. Suddenly you need to modify code written by total strangers, often either way smarter than you, or worse, quite opposite... and the simplicity of your neat application means nothing in face of complexity of the framework engine.

Comment Re:Lots of links to articles, phfft (Score 1) 232

You write 10 small functions, each a small non-trivial piece of code. You write one small function that binds them together. Next person after you needs to hunt around 11 files in the code to determine how that works and why it doesn't work to specs, instead of having the whole "device" right in 2-3 screens. Never mind if that's 10 + 1. What if it's 1000+100+10+1?

Or you have 6 different places where given piece of data is used, and it's used in 6 different slightly different variants. So you create these 6 methods - say, getters that in absence of valid data either supply a default, or throw an exception, or request the data and block until provided, or bypass the cache, or provide the data if not manually overridden, override value otherwise... and you write a 7th function, and now you need to dig through all the variants, only to find none of them suits your needs and you need to write a seventh one. And it's about impossible the next person will need your specific variant, but still - you moved the adaptation of input out of logic, and put it next to output of data storage. Would be a laudable endeavor... if it wasn't so counter-productive!

Slashdot Top Deals

It is better to live rich than to die rich. -- Samuel Johnson

Working...