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


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

Comment Re:Happens with the older guys too (Score 1) 294

Indeed, a successful model. The right team mix with the right level of experience and enthusiasm can really churn through the work and get stuff sorted. Team of 8 where I am - 4 under 25, 2 mid 30s, two over 45. The trick is to understand what everyone brings to the team (invariably different skills), and to totally ignore upper managements belief that everyone is equally capable and interested in tackling every problem (you're all developers right?).

Comment Their criteria are weird (Score 1) 315

C is a small language, certainly compared to the others in the top of the list (Java and Python libraries are just huge). By using postings and general 'chat' about languages to gauge interest, i'm a little worried that people attempting to get their head around the larger language libraries will be taken as equivalent to what will most likely be more targeted chat about C. To me this would suggest that C is probably underscored, whilst larger languages will be overscored if using this sort of approach (not that i've dug properly into their methodology!).

Comment Why not just ask the developers? (Score 4, Insightful) 122

You know, if you asked me which bits of my code where the hardest to write, and likely to contain bugs, I can tell you. In fact, I usually comment on code reviews in this way to help direct a reviewer to the bits I think need attention. Being self-critical is a very useful skill, accepting your limitations, asking others to help.

Comment Re:Oh, sorry about that 132M EUR? (Score 1) 157

I think you've got the gist of my suggestions, and the implications.

As for community meetings, yes, i've attended a fair few. As for people being idiots, I think you'll find it's a bit more complex than that. The majority of people aren't used to speaking in public, many are uneducated, and a number will have very weird ideas. Collectively though, there will be a consensus which is likely to be conservative, and distrustful of change, and from experience will at the same time be sensible and pragmatic. You have to discard the outliers and seek the consensus which can be difficult, but you'll find it rather rewarding if you try.

Comment Re:Oh, sorry about that 132M EUR? (Score 3, Insightful) 157

There are heaps of scenarios which would lead to a different conclusion if, for example, the company was dishonest. Apparently, companies sometimes don't tell the truth. It would be quite possible for the company to not have built what it applied for, or for some important facts about the plan to have been omitted, or intentionally mis-represented.

Another possibility is that the planners are corrupt, or simply incompetent and the application should have been rejected.

As has been suggested, it's possible that the residents messed up, but i've a feeling this is unlikely.

I imagine an appeal will get to the bottom of this, and some sort of compromise would be the most likely outcome.

Comment Re:How do people optimise their designs? (Score 1) 213

Well, when targeting a machine with large numbers of cores, memory and power, sure - it's a better tradeoff to avoid too much optimisation, and go for maintainability over raw performance. I know that, I do this all the time. As for writing assembler, my assembler days are long gone. The last I did was a bit of 56k maybe 10 years ago for an audio pipeline. The closest I get these days is looking at the output of the compiler ;-)

However, when the user base is continuously worried about battery drain, how do you design a sensible tradeoff between memory use vs CPU time (storing vs re-calculating a given value), or knowing how to arrange data in cache lines to pull data efficiently through the memory bus to reduce runtime (and hence prolong battery life).

These devices are power constrained, and will be no matter what anyone says. Knowing the architecture, and the future direction of the architecture would allow devs to produce solutions that will scale, and be power efficient. Maybe you'll only get 10% power saving, but for a device which is being heavily used, this could translate into an hour or two of extra use which is going to be a big selling point for expensive handheld devices.

Comment How do people optimise their designs? (Score 1) 213

I'm struggling to understand how apple get away with not announcing any info about the codes, the cache size, memory bandwidth etc. Surely on a mobile device with limited power, optimisation of applications is a priority. How do people manage this without any idea of the physical architecture of the machine they are developing for?

Maybe i'm just old school, but knowing what hardware you are targeting is almost the first bit of info which informs an efficient use of the resources available.

Comment Re:Michael Lewis's Vanity Fair article (Score 2) 46

I'm not sure where you heard this, or which market you think this works in, but that sounds dubious at the very least. The realisation that a trade isn't for a good price in an order driven market isn't obvious until further trading moves the price away from touch against the position you have just taken. You can't place one order off touch, the market doesn't work like that.

If, say, this happened on a major market (say NASDAQ) there would be a serious number of broken trade messages, or alternatively, some mechanism to re-instate an order which has been executed at the right place in the book (and there isn't). I can tell you there aren't a serious number of broken trade messages.

Have a look at the ITCH spec -

You can probably download a historical day of NASDAQ data, their main store is restricted to data licencees.

Comment Re:The ultimate ugly hack? (Score 2) 264

float->int conversion used to be expensive on x86 processors due to default rounding modes from C, and lack of suitable built in rounding functions. Looking back, my code contained this handy function. Ugly hack or elegant performance improvement? I'd suggest that the difference comes down to comments, unit tests, and whether people die if it's got bugs ;-)

#ifdef WIN32
        #ifdef ASSUME_ROUNDING // This method relies on knowing the rounding mode of the float processor // // It relies on it being set to round to nearest and offsets the value to // calculate a truncation
                inline int convert(float f)
                        int i;
                        static const float half = 0.5f;
                                fld f // f = f
                                fsub half // f = f - 0.5
                                fistp i // i = round(f)
                        return i;
        #else // Shift the bits in the double around so that the bits can be read directly as an int
                inline int convert(double d)
                        const double D2I = 1.5*(double)(126)*(double)(126);

                        double temp = d - 0.499999999 + D2I;

                        return *((int*) (&temp));
#else // On Mac we just use the standard C conversion since it doesn't suffer the performance hit // as on PC
        #define convert(x) int(x)

Slashdot Top Deals

Scientists will study your brain to learn more about your distant cousin, Man.