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

 



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

Comment Re:NoSQL all the way down (Score 1) 332

Postgres / HSTORE could have probably solved pretty much the entire set of persistence use cases

Hey, but PostgreSQL is buzzword compliant with the new hipness... you want a JSON-based document store? CREATE TABLE docstore ( docid SERIAL PRIMARY KEY, userid INTEGER REFERENCES users, document JSON );

OK, don't code-review that off-the-cuff doodle too seriously, but implementing NoSQL features in a decent RDBMS is easy, implementing RDBMS features in NoSQL is hard...

Yep. I've worked two projects now that include Cassandra. Why? Replication. All the queries are SQL/Relational oriented. The one project supported Sqlite (for dev testing), Mongo, and Cassandra but they wanted to deploy with Cassandra; the project got canned after it was nearly complete and they started looking at the operational costs to meet our required throughput (requests/second) because of how massive the Cassandra cluster needed to be (in terms of node count and the type of server needed to support it); though we were officially told it was canned for other reasons, the timing was just too close to not have been a major factor in the decision.

Comment Re:What Hollande says (Score 1) 328

"theoretical ways to deal with the waste products" = "no actual ways to deal with the waste products"

Actually there are very simple ways to take care of the waste products, but either (a) environmentalists and the EPA get in the way, or (b) we've removed them as options via International Treaty.

The simplest way to deal with waste products is ship into space - and we ship usable nuclear material - working nuclear reactors - into space regularly for use by satellites, etc. So yes, it is a perfectly viable to method to get rid of it - sent into a dedicated orbit around the solar system or to be consumed by the Sun at some point (months) in the future. However, this is banned by International Treaty - one of several treaties signed during the Cold War, primarily to keep nations from sending Nuclear Missiles into space for use (f.e see the movie Space Cowboys - yeah, not doable by Treaty).

So yes, there are ways to deal with it if we decided we really wanted to actually deal with the waste products.

Comment Re:Good ol' fun (Score 1) 302

They have 1.2 million users. That's big enough to have an "email server admin." In fact, it's big enough to have two. They should get some. Not having any hasn't worked out too well for them.

Well....if they're using MS Exchange they'd need a team of 4 or 5 at least. So yes, someone should have known how to set the groups properly so that this could not happen. Of course, that's assuming it went to "Everyone" or a similar all-encompassing group. It could just as easily been a single email that contains a bunch of groups too...read TFA to find out (I would assume).

Comment Re:yes they should (Score 1) 1081

WE DO HAVE A DEMOCRACY. AMERICA IS A DEMOCRACY.

No, we do not.

A Democracy means that there is direct elections - every vote directly influences the voter outcome.

What we have is a Representative Democracy in the form of a Republic where elections are for representatives that are tasked with making the real choices - there is no required direct election of the representatives. Yes, some representatives are directly elected; others are not. Voter influence is by design indirect.

Comment Re:It's not surprising... (Score 1) 176

In an enterprise there are two big costs... licensing, and support.

Linux the cost of support is pretty high -- for models like Red Hat the cost often is higher than Windows because you don't get as high a per-seat discount. Then there are the other ancillary costs like productivity, accessibility, data governance, etc... which are harder to materialize but also make an impact.

So here's the thing:

With Linux - you *might* have a support cost (e.g RHEL/SuSE/Canonical Enterprise support agreements), infrastructure to run, a few engineers to maintain your specific packages, and your normal support staff.

With Windows, you still actually have all of that, plus you have to the licensing for Windows itself, the servers, etc. Windows Server requires licenses for clients to access it - so you pay twice for each user (WIndows Desktop License + CAL on the server).

The enterprise support agreement costs between RHEL/SuSE/Canonical and Microsoft are actually pretty comparable. So ultimately you *do* save money.

However, most organizations that deploy Linux don't heavily customize it like Munich did with making LiMux. Most will just use what's provided via one of those Enterprise distros, use their support, and infra, etc. They might deploy a local mirror (to reduce bandwidth charges and be friendly), and may be a repo for their software additions - but not likely.

So ultimately arguing that people and infrastructure makes Linux more expensive to deploy than Windows is also inherently false. Aside from the licensing (not support, but actual licenses) cost everything runs generally the same; if anything you'll need *more* people to operate the Windows systems simply b/c one Windows administrator has a lot more work to do to maintain a Windows environment than 1 Linux/Unix administrator ever has - which is why you typically see a 1:50 to 1:100 admin to system ratio with Windows (and I'm being generous) while you normally will see a 1:500, 1:1000, or even 1:10,000 with Linux/Unix.

Comment Re:No surprise (Score 1) 167

Well, let me see how really detached I am from technical work: At start of project: My estimate: 490 Story points, +2 senior developers, +1 senior QA, 3rd party cost $20k, GA in 9 months The team estimate: 305 Story points, no new headcount needed, 3rd party cost 15k, GA in 8 months

It's a matter of how much dev work you are doing versus management work. The more time you spend doing solely management, the less you'll be in touch with real dev estimates, etc as it's impossible to keep up both skill sets without actually using them.

I constantly have to tell the team their estimates are low and unrealistic, as I hear them not discussing corner cases, they take it as an insult to their pride that their estimates are accurate, yet 5 releases down the line they consistently underestimate by as much as 80% and miss release dates by as much as 9 months. Where we were supposed to have a team if 16 senior people, now we have an ever growing team that lastly counted 40 junior people. Every 2-3 months RND management see that they are behind, go out and find some guy fresh out of college, 2 or 3 other developers take 2 months to train the new hire, and as a result we are getting even farther behind, while the new guy is only interested in refactoring to the latest technology buzzword instead of writing new functionality. Refactoring is important, but I generally prefer to have the most senior guys do it, and only after they have been tasked by the Architect to do so.

Sounds like (a) you need some good lessons learned taught among the team, and (b) you need to be applying the standard practice of PM Estimate = ((Dev Estimate * 2) + 20%). Devs are extremely bad at and are not taught how to estimate effort; spend the time to teach them how instead of complaining about them.

Comment Re:No surprise (Score 1) 167

Most devs have no clue about project management from a business perspective; your more seasoned devs will (or at least should). "No" will rarely mean "No, that can't be done"; they have to learn how to speak your lingo as much as you need to learn how to speak theirs, and a good PM will help both sides do that.

That's the wrong way around. If you're the project manager, you got hired partly for your people skills. Developers get hired primarily for their technical skills. It would be easier for a good project manager to learn to speak geek than for developers to speak business.

Devs still need to learn the language of management. Even if they don't go into management it will significantly help with (a) understanding management, and (b) communicating with management; thereby making life a lot nicer. It helps when talking to the PM too; but the PM should be able to talk with the Devs in their lingo - IOW, Dev-Dev is pure dev speak; Dev-PM is mixed dev speak and management speak; PM-Management is pure management speak.

Besides, developers tend to be worse negotiators, and if they're talking a foreign language they'll be even more at a disadvantage. One defense a bad negotiator has is to take a position and stick to it.

Experienced developers are sometimes gun-shy. If you're trying to do a job, and say "We can do it if we get X and Y", and find that you're expected to do it just fine without X and Y, and your complaints get stonewalled, it's going to be much easier for you to say "No, can't do it" next time.

It's possible to wind up in a situation where developers and managers are on the same side, but that usually requires management to understand developers and keep promises.

Consider that many senior devs will eventually do some level of management; it helps to learn the lingo. You may not be good at negotiating right away, but building up the toolset is a good thing nonetheless.

Comment Re:No surprise (Score 1) 167

What I have found out, there are some cultures that say "No" when in fact they mean that they won't be able to do it with current resources. Which is absolutely fine to disclose, but for some reason, they don't do it. They just say "no".

Most devs have no clue about project management from a business perspective; your more seasoned devs will (or at least should). "No" will rarely mean "No, that can't be done"; they have to learn how to speak your lingo as much as you need to learn how to speak theirs, and a good PM will help both sides do that.

Often PMs aren't unreasonable and don't expect that features are for free. It is perfectly reasonable for a Dev team to present cost estimate which is not only story points but also headcounts, equipment needed, account for decreased productivity and opportunity cost.

Aside from the MBA speak you have in there...you are obviously detached from the team in any meaningful manner. You might have had a technical background at some point, but you've lost it due to going down the PM/MBA path, and have forgotten how hard it is for developers to do any kind of estimates. That is why you have senior developers and software architects that are in charge of the project as a whole and its general road map. You as the PM need to be working with those people - 1 or 2 people that will really know the product, its source, and customer base really well - to get the estimates, etc you need. They should in turn be training the lower devs to be able to do the same (though that almost never happens) while they collaborate to get the estimate figured out.

Then it is up to the PM to present and defend that cost to execs in a cost/value analysis and if numbers work out the PM can actually help the team get funded and get the job done. But if the team only says "no" instead of "yes, but ..." by providing a complete analysis for a means to make it a "yes" sometimes it just doesn't get to a "yes" and the whole product gets scrapped.

Wrong. The PM is but one part of the team in deciding on the estimate. Their job is to help identify what is valuable to go after and work with the team to build up an estimate and make the case. Their job is to run the financials for the team, ensure there's enough developers and resources, etc. Their job is to be the voice of the team to fight for the product in the organization, to ensure it get appropriately marketed and arrange for all the other non-technical stuff that goes into the product while working with the team to get the technical stuff completed.

Sadly, this is where the MBA/PM courses fail. They focus too much on looking at this in an unbiased manner based on balanced sheets; team work is against other CxO's, and the people that do the real work are turned into "resources" that can be "allocated" without any information or regard for what those "resources" really are. That's not to say that there is not a place for that kind of perspective (there is) but it's not how you should be looking at it the vast majority of the time.

Comment Re:Never can though (Score 2) 167

Even if you can reproduce all of the hardware exactly, you are never going to get the same kinds of results that putting software in the hands of real users will get you.

There's different kinds of buys, which is why you have different kinds of systems and testing environments.

A dev should be able to have an isolated environment in which to be able to test the various parts. Each part should be able to have a sufficient emulation of external parts to be able to have its own unit and functional testing. From there, several parts should be integrated at a time to do functional and integration testing, eventually building up to the entire system being fully integrated and using emulated externals (e.g external auth emulation) so the system can itself run in isolation. This gets to 95% of the issues.

From here is scalability - for which the operations team should be providing environments sufficient to do the scaling testing so stuff can be tested at sufficient scale before it hits production.

Now, that doesn't mean you won't end up with issues in production, but that it should be a rare thing for that to happen. In those rare cases you may have to test in production, but that should be the exception, not the rule.

Too often we don't invest in all the different levels of testing b/c (a) devs are lazy, and (b) management cheaps out. However, doing all the layers of testing will be cheaper in the end since things will be caught earlier where it's cheaper and faster to fix.

Comment Re:No surprise (Score 1) 167

Most developers should do their job faster and with better quality and stop arguing with their Product Managers.

Well, Devs *should* argue for things that need to be in there, but yes they should also be professional enough to do what is required to make the product available to customers (certified and all). However, a PM also needs to find a way to make everything fit within the guidelines. It may be that a given feature the PM is arguing for breaks something else that is also extremely important. Thereby if the PM doesn't have a development background then they too are dysfunctional and only being a hindrance to the team and product.

Either way, professionalism goes both way. Work with the team to make the feature some feasible for the product.

Comment Re:Not gonna help you (Score 2) 280

How many house fires start because of the roof catching fire? Seems pretty unlikely for freestanding structures...

A massive shitload, actually. It's unusual for it to happen to one house, but it's very common for it to happen to a whole bunch of houses during a general conflagration. During forest fires, it's not unusual for burning debris to be thrown for miles

In areas where such things are common (South West US, California, Eastern Washington) I could probably agree. But they are not common in most of the US.

Comment Re:A bit of hyperbole (Score 1) 176

Stolen -- incorrect and inflammatory verb use.

Unattributed -- The repo is named "wix/WordPress-Editor-Android" ... I would call that a pretty explicit case of attribution.

Wix seems to be in compliance with the GPL. The source for the entire version of their editor is available on GitHub. Matt Mullenweg seems to be aware of this repo and yet he insists that there is some additional and unidentified code that is not publicly available. When one uses terms like "stolen", it is irresponsible to not be explicit about the details.

The question is if the distributed Wix mobile app linked to the GPL code. If it's linked, then you also need to post the source code to the Wix mobile app.

Depends on how it is linked - https://en.wikipedia.org/wiki/... - but you could be riding a dangerous line.

That said, I opened up Wix's GitHub site, did a search for "word" and found 3 repos - 2 were forks, and the third is likely the project in question. Analyzing that third project (licensed under a MIT permissive license) - it's got some Java (Android) and Objective C (iOS) code; and I think you'd be hard pressed to call it linking by any form. Both rely on a third party parser to do the JavaScript interactions (as applicable for each OS) using WordPress JS API names for sake of the parser and interfacing appropriately there. So it's very likely in that gray area of controversy - an area not well covered by the GPL or community norms; and the App store policies don't help matters at all either.

Comment Re:not that complicated (Score 1) 176

t's to cover proprietary apps using GPL dynamic libraries loaded at run time. Otherwise developers could use GPL code in their proprietary apps by just compiling it into a DLL rather than statically linking at compile time.

Admittedly even Rosen - one of the authors - admits there is a gray area regarding linking and where the boundary falls. (https://en.wikipedia.org/wiki/GNU_General_Public_License#Linking_and_derived_works)

Comment Re:GPL (Score 1) 176

Take for example a GPLed game. Now somebody comes along, takes all the graphics and releases a proprietary game with them. Is that a violation or not?

Absolutely a violation of all GPL versions.

Actually you may be surprised. The Assets may not get covered by the GPL at all; they're probably better licensed under the FDL (Free Documentation License) which is meant to cover non-source material. GPL doesn't cover everything that goes with a program.

Comment Re:GPL (Score 1) 176

>Whether the memory space is shared is nothing to do with the legal text of the GPL.

Actually it absolutely IS what matters - which is EXACTLY why THAT is where the GPL draws the line - because it's where the LAW and Court Precedent has drawn the line. Because once the code shares a memory-space, it becomes part of the same greater whole - and THAT is legally a derivate work. If, at no point, do the two pieces of code combine into one thing - then it's not a derivative work - just two programs which coexist and copyright does not apply to that.

Shared Objects (*.so) (dynamic linking) on Linux do not necessarily share the *same* memory space when loaded for use by a program - especially with the Automatic Random Address Loading that has been happening of late to increase security . Focusing on memory space is a misnomer that will not get you very far.

Now, Windows provides an interesting case as it has two types of Dynamic Linking - one which operates identical to the Shared Objects on Linux/Unix, and another that makes a dependency on the associated DLL. The hard dependency on the DLL probably will be triggered more like a Static Link, but it can be quite murky.

So again, you're left with the questions of: (a) is the library essential for the software to run? (b) can it be replaced without modification? That is, if you didn't have the library at all, would the program still work on its own - possibly in a degraded state? If so, then it's non-essential and not a derivative work. This is how most plug-in style programs function, and thereby a GPL plug-in for a non-GPL-compatible program doesn't affect the main program.

And if you can replace the library without modifying the program then you are solely dependent upon the API. Some communities are okay with that kind of linking without requiring the same license, some are not.

Of course, devs are best to make sure any library is LGPL instead of GPL and you get around a lot of things. Very few libraries are solely GPL or AGPL for exactly that reason.

Slashdot Top Deals

An adequate bootstrap is a contradiction in terms.

Working...