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: In other news (Score 1) 167

A quick google of "problems with Git" will quickly reveal the various challenges that git brings to the table, for example git push --force. More generally, any team using git needs to decide on a workflow and carefully adhere to it. How do we manage merge workflows? To rebase or not to rebase? etc. With traditional source control, this is significantly easier.

I'm not anti-git, far from it. I introduced Git into the company I work for and love it; and it is absolutely the best source control system for distributed teams that exists. If you have distributed teams, it's an absolute must. But if you can't see that it's more complex, then you obviously haven't had the wonderful experience of having to field complaining from 30+ developers and having to fix the amazingly inventive ways in which they have managed to screw things up.

Comment Re: In other news (Score 4, Informative) 167

The problem with git, and I don't see it as a major problem, is not that it's hard to get up and running, but rather that you can quite easily get into the kind of trouble that needs expert knowledge to get out of. If you don't happen to have a git expert handy; well, you are going to have a very bad day. In this git shares the same problem as most very powerful tools, for example C. So I agree with the original poster, if you need the facilities of git, then you'd be an idiot to not use it, but if you don't, then other tools are better for simpler uses cases. Much like using something like python makes a huge amount of sense for certain applications, and zero sense for writing kernels.

Comment Re:SSRIs (Score 1) 47

No, the SSRIs cross the blood brain barrier on a time scale of minutes and inhibit the re-uptake of serotonin leading to a massive spike of serotonin levels on a time scale of hours. But the claimed effect (depression cured) takes place on a time scale of weeks or even months.

Which is why this study is so interesting. It essentially replicated this exact effect. The mice had decreased motivation (locomotion speed) after directly tinkering the serotonin up, but over a longer time scale they had increased locomotion from their base levels. Essentially replicating the human experience, and providing a much more direct way to study the effects of this particular chemical. This is interesting science as we still have very little understanding about Serotonin.

Comment Re:SSRIs (Score 5, Informative) 47

As someone who's seen SSRI's "work" on people you most find that they lose what they want to do. For some people want they want is unachieveable, but when someone else wants to be a functional person and instead sits around all day and ends up not wanting to get better, that's not an improvement even if they feel better. It'd be interesting to see them continue this in the face of challenges, like shock floors or social situations.

Which is exactly what they did and you clearly didn't read the article.

“But the same stimulation does not have any effect if the animal is already engaged in a specific task such as running to get a reward”

The decreased motivation (physical movement speed) was only temporary. The study showed that over a longer period of increased Serotonin, locomotion speed was up by 30%-40% from starting levels; the researches are looking at this as an explanation as to why SSRI drugs take about 3 weeks to start working.

Comment Re:C# vs Swift (Score 2) 85

The argument made here in reference to the paper is that ARC is a useful strategy when considering performance in relation to physical memory size. The throughput/latency trade-off is important for mobile applications, but as you mention, some implementations of a GC can perform well for latency (which is obviously crucial for a mobile app). The enormous performance penalty as the GC heap size approaches the amount of physical memory, however, is a major issue that cannot be easily worked around on a smaller device (That paper is somewhat dated at 2005, so perhaps there is a GC out there who's performance does not degrade as memory consumption approaches the limit, however I doubt it. It's a bloody hard problem). So the choice is an obvious one; slight over-all performance penalty for good latency and memory footprint performance.

Comment Re:Trump honest? (Score 5, Insightful) 283

some people think he's honest

and

he's not honest by any measure

are not in conflict. Trump uses profanity to appear honest; and as people associate profanity with honesty they attribute "straight-forward" and "honest" to his persona (I'm not American or pro or anti Trump, just an interested outside observer). Bullshit is an art, and he's better at it than most.

Comment Re:Hate the office life (Score 1) 250

A few comments on this post. Total cost for an Indian developer is 1/3 of the equiv, not 1/5. Performing your own hiring will get you competent people, but it doesn't solve the problems. Software developer is not a career in India, it's a stepping stone to something else. You simply cannot build the depth of experience that you need to do anything good, with no one who is any good sticking around for more than 3 years (I mean in the field, not in the one job). This is the key problem with India. You can't hire good people with experience, because they are now managers.

Comment Re:It might be agile, but it's not Agile (Score 1) 332

The way you describe what you are doing it sounds like you know what you want at the end of a fairly long time frame, and your doing one set of pretty basic planning and then acting surprised when that plan doesn't give you what you want at the end of the project. This is pretty typical when groups try to transition to an agile development process, and fail as a result. All you've done is throw away your detailed planning and chunked your work up into sprints.

Try Scaled Agile.

It's what we currently use and is the best tool-box that I've yet come across. Things like SCRUM etc don't define process at the business level (intentionally), nor do they describe how you plan out a project that's going to take a year or so to deliver. Scaled Agile does, and it's a very useful toolbox for getting the whole show to be agile (which is the end goal for a business as it allows the entire business/activity to adapt quickly to changing conditions, both internal and external). At the very least, it's useful to read (all online), as it demonstrates all the extra bits that you would need to transition fully.

Comment Re:It might be agile, but it's not Agile (Score 1) 332

A core tenet of Agile is that design, planning ahead to the end of a project, is impossible. In fairness, it probably IS impossible, for the people who believe that.

I'm so glad you're here as an obvious expert on all things software development process to explain Agile in such detail. It's so comforting to have a real professional help all us struggling dolts see why we've been getting it so wrong! I don't give two shits how you like to run your projects, but maybe you should stick to talking about things you know something about eh?

Comment Re:Agile is good for some teams & projects, ho (Score 1) 332

Central to Agile is the proposition that the company is unable or unwilling to figure out what the requirements are before they develop the system.

Garbage, you simply show your ignorance. You know what? Agile is a meaningless term, you have some kind of image in your head of what it is (maybe informed by some group of idiots claiming to do it), and hence you can build this lovely strawman to set fire to. Here is the agile manifesto:

- Individuals and interactions over processes and tools

- Working software over comprehensive documentation

- Customer collaboration over contract negotiation

- Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

No mention of not bothering with requirements, only that the emphasis when creating your processes is on the ability to respond to change. On any project that lasts more than a few months, that just sounds like damned smart idea. "No no! We must continue to follow this plan from a year ago, even though it no longer makes any sense in the current market!" Been there, done that, have the t-shirt. (You always get a t-shirt, no matter how big a balls-up it was).

Comment Re:Agile (Score 1) 332

Ever tried Agile development of a software library or of infrastructural systems? Stuff that needs to be thought out before publishing? Where experience counts? Where you don't have a team of 10 people dedicated to sprints of two weeks? Where produced software actually has to be maintained? In short, where you have a small shop that needs to make a difference.

Yes I have, SCRUM was the process used, and it all worked vastly better than the three failed projects before it (in our extreme waterfall shop). There is nothing magical about SCRUM, or any other process, it's mostly about letting good people do good work. The thing that SCRUM et al, gives you is a tight feedback loop, and that is a very useful thing if you have it all going nicely. I've worked in all kinds of setups, from super heavy process (which I just can't stand, who wants to sit around for 6 months just writing documentation and attending meetings?), to extreme isolation (here are the requirements, give us the result in 6 months), to agile of all different variations. I like SCRUM the best because I like working with other people, I like that the work is chunked, and I like that it deliberately only describes a tiny tiny part of the process. There are so many ways to do anything wrong, so many things that end up working despite human screw-ups, so little hard science around anything people oriented, and so much implied in vague terms like "agile" that these discussions are meaningless. Give me a couple of Devs of at least medium ability, a tester or two that know the product domain, and someone on the business side that is willing to talk product, and I can deliver you a successful project every damn time. Call it what you like.

Comment Re:Multithreading is a solved problem (Score 1) 497

Yes, and if you follow this golden path, what does it give you? Nothing more than asynchronous behaviour. And there are much better and more robust mechanisms to achieve this (such as co-routines, or their virtual equivalent such as async await in C#, message passing, etc etc). What it doesn't give you is any kind of scalability across multiple cores, and the level of complexity is all out of proportion to the gains. Multithreading particularly in combination with OO, has largely failed, because the paradigms were simply not good enough.

Comment Re:hey, you got your computer in my PLC (Score 1) 59

Exactly. What is more new is updating the PLC remotely, IP based networking to PLCs, more standardisation of PLC operating systems, more network connectivity between SCADA networks and the outside world, and far more activity by state actors in industrial automation. At the end of the day, a PLC is a computer hooked up to a network card, connected to another computer running SCADA most likely on windows. There is a lot of security and obscurity that makes compromising these things hard, but there is an awful lot more that the big vendors could be doing to harden things from a PLC security point of view.

Slashdot Top Deals

Enzymes are things invented by biologists that explain things which otherwise require harder thinking. -- Jerome Lettvin

Working...