Catch up on stories from the past week (and beyond) at the Slashdot story archive


Forgot your password?
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:Object relational impedance (Score 1) 525

Well, we don't happen to have money to hire a database designer, to invent the SQL queries that would do what 20 lines of Perl over JSON file can do.

Actually, we do use the relational database, except for the most wildly varying entries, there's a text field, which contains the JSON objects. I mean, if the field "measurement" may be an int, a float, an enum, an array, an array of arrays of variable length, containing int, float, NULL or NaN, or a structure composed of a string and three booleans, yeah, that can be normalized into a bunch of tables, and queries for these can be written, but... seriously, why?

Comment "I'll be ready for extensions." (Score 1) 525

"If I write this program in an easily extensible way, expanding this later will be a breeze."

Lots of classes, rich inheritance trees, broad project on top of a robust framework, making adding extra modules fairly easy. Your program is clean, well-documented, and has a logical structure, all according to best practices. It's also about 4 times bigger than it would really need to be, it takes 3 times as much RAM (primarily due to loading all the neat frameworks and libraries that you used "not to reinvent the wheel" even if you only use one or two simple functions from these), but who cares, this is the modern paradigm, and everything is automated and works so smoothly you can be nothing but proud of it. Now just to support it, fix some bugs, and implement extra features.

Then the new requirements arrive, you look at the email, you look at the top level schematics of your system and you realize, with a sinking feeling, that you never imagined the system would need to be expanded *that* way. And that this particular framework doesn't support this approach, and never will, because its authors decided they never plan to support it, or that the target platform doesn't support, and can't ever support the kind of libraries you use, or that you currently depend on a piece of hardware to do a job which you will need to write from scratch, or the new legal requirements (which are not disputable; new law says so) go completely against your system philosophy, which provides equivalent but completely different functionality, or the essential library just has been discontinued, and new security holes have been found in it...

Or at the very least, you realize that a feature that amounts to ten lines of code performing a really simple tricks requires you to create ten different files, two thousand lines of code, config and extras, and modification of several existing files, because the way the extensions of this type are applicable is writing a plugin which is a separate project with a whole non-trivial instantiation of framework, build system, security, and compatibility with your smart dynamic plugin loading mechanism. What would amount to pasting a 12-line function called once per tick from the main loop, amounts to a three-week project building the plugin/wrapper for that 10-line snippet.

You CAN NOT foresee future requirements. You CAN NOT plan all possible future extensions ahead of time. And the more you plan for, the more "flexible" you try to be, the larger and more rigid your project becomes in areas you failed to foresee, and the harder it will be to adapt it for these.

Yes, leave hooks for stuff you have it on a good authority WILL happen. Do not try to plan for every eventuality though. Write good clean code that does what it's meant to do, and doesn't try to be ready for anything else. It will be *easier* to expand once the time comes.

Comment Re:Mint (Score 1) 499

Ubuntu has a very solid backend/engine, but the frontend has been dumbed down to the level of a Fisher Prize toy.

It's a decent way to get started with Linux from zero, and a good thing for people who are computer-illiterate, but if one day you get tired with Ubuntu behaving like an overprotective mother of a 3-year-old (with you being the 3-year-old), just sudo apt install kubuntu-desktop to get a reasonable frontend replacement.

Comment Re:Hit Job on Google? (Score 3, Interesting) 293

No, News Corp has been doing this for years. The reason is Murdoch thinks Google and Google News specifically is killing the news industry, and that the iPad will save it (or at least he thought that a few years ago). It's pure inter-corporate warfare being played out through manipulation of public opinion. The WSJ in particular are experts at it.

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) 520

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) 234

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.

Slashdot Top Deals

Chemist who falls in acid will be tripping for weeks.