Become a fan of Slashdot on Facebook

 



Forgot your password?
typodupeerror
Check out the new SourceForge HTML5 internet speed test! No Flash necessary and runs on all devices. ×

Comment Re:Gotta love the Employee Improvement Plan... (Score 1) 387

Sheesh creimer, you should have parallelised that script in your free time and run it on the non-existent compute cluster ... blah blah blah.

It's the jobs without slack time where the mistakes get made (at all levels). Let the employee kick back occasionally, surf the web (hell, reading technical websites is hardly the worst thing you can do in a technical role), do things safely.

And hell, if your manager has told you to only do one task/story at a time, then who am I to say you shouldn't!

Comment Re:employee improvement plan (Score 1) 387

Only do the things in (3) that will help you get a new job.

The EIP will not be "Just do X, Y, Z", it'll be a weekly-reviewed self-documented long list of things to be attaining. If the company is reasonable, it will be doable. If they want you out, it won't be - so just concentrate on the things that you like the sound of the most, and avoid the soft-skills crap that is hard to quantify.

If the cause of lower performance is transitory (say, a year long divorce/house move/depression type thing, and the employer is still being harsh on you) then it can be useful to switch job anyway - new jobs are more interesting, learning opportunity, no historical weight, often little legacy crap to deal with - just concentrate on getting through the probation period and hopefully things will ease up in your life (and the stress-break from changing job and losing the EIP will help massively) and then you can move on and forget the bad year or two.

The biggest issue for an employee is under-motivation and/or procrastination (as in, serious internet addiction level) that is not transitory. In that case, well, yeah - visit all your sites in the evening, leaving the morning at-work surf fairly minimal. Hope the work place blocks sites. Etc.

Comment Re:employee improvement plan (Score 1) 387

Yes, small teams that work together, who own their own projects, where the projects don't get large (create new projects for new functions) and who aren't held back by external forces as long as they generally follow some basic rules (language, db, api structure, documentation, builds, and so on) generally can get things done.

Super-large old monolithic architectures that have been appended to over many years and now have a team of 30+ basically maintaining it and desperately splitting the tangled code into seperate services talking via RMI to keep development time down, until they hit serialisation versioning hell, and then morale drops and everyone wonders why the front-end ajax interface is rendered in the server side via some weird codified templating system that results in tears instead of hiring people who know Javascript for the front end and trying to do things simply, cleanly and concisely... well yeah, that can get skilled people down.

The first case - you have a team owning N microservices. Team gets too big - the split is easy (well, easier than the second case of having separate teams own parts of the same monolithic codebase), two smaller teams, each with N/2 microservices. Best keep some FE and MW on the same teams though, don't go the route of FE team and MW team, that way leads to more intra-team communications.

Comment Re:employee improvement plan (Score 1) 387

Using your example... that depends on whether the programmer is in a role that should be talking directly to the database, has self-identified (e.g., at interview) as knowing SQL and programming language interfaces to it, or has received training in-house to that level via whatever means.

Maybe the symptom isn't a bad programmer, but an in-house process that doesn't work - in this case maybe the company has an in-house DBA team that does DB programming work (and teams that create microservices that interface with the DB), but they are overloaded or don't respond to work tickets. The programmer has just tried a workaround to get something going rather than being blocked by the process for 4 weeks.

(yes, I know that any reasonably experienced programmer should know SQL to some level, but these days it's very easy to go years and years without touching it directly)

Comment Re:Umm what?! (Score 1) 387

Yup, improvement programmes usually exist to document the failure of the employee to meet the demands of the programme, which are set to levels that can't be achieved day-in, day-out over the programme period. Obviously if there is an external issue creating the employee's problems, the programme simply adds stress to the situation they are in rather than even being anything like being a helpful assistance through a temporary situation.

It's usually only when that employee eventually leaves and finds another job that they realise the expectations of productivity from the previous role/programme were not attainable.

At the root there is always a bad manager.

Comment Re:Why does Iceland the country care? (Score 1) 102

1. The supermarket's name is the full name of the country Iceland, and that's that. It's a source of mild amusement in the country to deliberately confuse the two, especially with the company's adverts which use "Mum's gone to Iceland" (because Dad didn't give her enough money to go to Waitrose, I presume, and other misogynistic themes).
2. But in English, not Icelandic.
3. And also the supermarket started off (and still mostly is) a specialist in low-priced frozen foods - hence the name - it wasn't named after the country.
4. The supermarket is enforcing its trademark to stop companies from Iceland use 'Iceland' in their name.
5. The country believes that this is unfair.
6. Maybe the country should consider some more exciting branding around volcanoes and rifts for their companies. 'Horsemeat Iceland' is all very well, but "Erupting Mid-Atlantic Ridge Horsemeateries" sounds better.

Comment Re: Oracle != Mongo (Score 1) 153

What sort of transactional consistency do you require?

Do you care if it takes a short period to replicate across the cluster before it can be read again? NoSQL solutions include options, if you need that (e.g., i don't care, i want a quorum agreement on the read, all must agree (read from master, enforce writes through master), etc). Indeed these options are often what distinguish one NoSQL solution from another.

Are you only modifying a single document? Then you can do that atomically. Remember that document may represent a lot of tables in a RDBMS.

And maybe this use case is simply not suitable for a document database. RDBMS is great at these things - it just isn't great at some things NoSQL is great at.

Comment Re:Oracle != Mongo (Score 1) 153

Why are hundreds of people working on the same objects directly? That's screaming for a microservice interface on top for the 95% who are doing the same operations. And then suddenly the underlying system doesn't matter.

Most NoSQL solutions have a structure to the documents (because in the end they're serialised forms of Java/C#/etc objects), it's just that it isn't columnar. There can be arrays, inlined sub-objects, etc. And you can set indexes on these deeper aspects, and so on. The DB is optimised for tweaking at the object level of course, and locks at the object level (but doesn't provide multi-object transactions out of principle).

Some NoSQL solutions add some very cunning features to how you can define the structure of the data, you can do some funky things with Cassandra's slices, for examples (although it's been some time).

Comment Re:could just be the beginning (Score 1) 153

Exactly. If your company can afford a DBA team, then Oracle is an option. This will likely keep the money rolling in to Oracle for the foreseeable future.

If your company can't afford a DBA team, then you really need to look elsewhere, where-ever that may be (IMO PostgreSQL and Cassandra, maybe MongoDB, maybe ElasticSearch stack) and do a short period of trialing / proof-of-concepting to see what works best. However in this case one suggested recommendation is that you choose ONE company-wide SQL solution and ONE company-wide NoSQL solution, and only allow exotics on a case-by-case basis when the need is demonstrated.

Comment Re:If all you have is a hammer... (Score 1) 153

TBH MongoDB 3.4 has graph queries. So assuming Solar Systems are linked by 'trade routes' or 'warp jumps' or even just linked to all systems within X light years, you should be able to use that effectively for route planning, getting all near systems, and so on, without a complex 3D geo-spatial lookup.

But it is application specific, without knowing the requirements, who knows what the use cases are.

But yeah, "Get System Trading 'Gold' Ordered By Distance From Me" is your typical space trading game query. I suspect MongoDB can do that in a single call to the DB. RDBMS might require you to do multiple steps to collate that data (or the most horrible of multi-table joins).

Comment Re:If all you have is a hammer... (Score 1) 153

You could have a massive relational schema, or you could model those items you talked about as documents in a NoSQL solution. I'm guessing that the ratio of reads to writes is skewed massively to the reads, so this indicates a nicely scaled sharded DB to handle the load.

Solar System: Name, Location, Attached (permanently) Celestials and Constructs. Lookup geo-spatially (3D) would be nice in the DB, to get systems close to you. Seems to map well to a document based storage.

Obviously you would cache it all in memory at run-time (write through for performance), but most DBs can provide that natively these days. What does a typical application store in memory - complex objects. Maybe that could determine what the backing permanent-storage DB should be.

Slashdot Top Deals

A man is known by the company he organizes. -- Ambrose Bierce

Working...