Follow Slashdot stories on Twitter


Forgot your password?

Comment Re:My sister endorsed me for something. (Score 1) 59

Anyone who is going to be so fucking stupid as to think worse of you simply for a family member giving you a silly endorsement on LinkedIn is a pretentious dumbshit anyway.

Or they just are going to take everything you say with a grain of salt, if it's pretty clear you are getting your family members to inflate your endorsement numbers. That's not being a pretentious dumbshit, that's simply not being a dumbshit, period. Either I can trust the numbers, because I can trust the people endorsing you, or I can't trust the numbers.

I'm pretty sure that if you're applying for a position as biologist, it's statistically improbable that all the members of your immediate and extended family are also biologists, and therefore qualified to judge your ability, or have an opinion. In which case, I will scale my opinion of your ability (down) accordingly.

Comment Re: "Open Sourcing Testing Frameworks"? (Score 1) 59

So how do you "test for correct behaviour of the products, overall"? It's not that hard to spell out -- and even automate -- the cases that a person expects to occur. The problem is accurately modeling the state space of the program and then figuring out which walks through it are incorrectly permitted. Even the most sophisticated known approaches fall down for the first part of that problem due to the vast size of an interesting program's state space.

Personally? If money were no object, I'd use software that cost thousands per engineer in about 1985 or so, but which is now sold as "McCabe IQ". By 1990 you could get three floating licenses for "only" $45,000 (not sure on the current precise price; it appears to *start* at $2,000.00/one-time/user, which generally means that a useful configuration would be more hefty in both price and capability than the "starter" version).

I'd use it to ensure that the requirements document is implemented by the software, and then do a branch path analysis on the resulting code to make sure that the test cases that get generated cover all possible code paths.

Given the substantial costs associated with the tools, most software engineers today have no exposure to *real* CASE tools (but if you care, you can obtain a 30 day free trial from them these days).

Obviously, it also possible to do this type of code coverage testing manually, but most test engineers are trained to do mostly ad hoc testing these days -- assuming you have actual test engineers on your project at all.

If you want a review of McCabe IQ, here's one from ~1990:

And here is a more recent company overview:

Comment My sister endorsed me for something. (Score 1) 59

My sister endorsed me for something.

I made her delete the endorsement, on penalty of being delisted as a connection on LinkedIn if she did not do so, since there was no way in hell that she could legitimately claim domain knowledge for the endorsement, or lacking that, experience in an organization we were both in, justifying the endorsement on the basis of my past work.

This is the problem with associating with family members on professional, as opposed to things like Facebook, social networks: they think they are helping you, when really they are not.

While there are several organizations where we both worked simultaneously, they were all in the distant path. If she wanted to endorse me as an electrician or a telephone installer, or a small appliance repair person: yes, she has that domain knowledge. But that's not where I typically work these days, and it's not right for people to comment on things they don't know that way.

Probably, you should have just given your realtor the same speech I gave my sister, and in the limit, asked them to retract or to lose their connection to you, rather than just deleting your account.

Comment Re:"Open Sourcing Testing Frameworks"? (Score 1) 59

My buzzspeak is a little rusty, but this sounds suspiciously like "Beat monkeys to code faster, send code out the door without testing, and just let the users figure it out". Did something get lost in translation?


They deploy to internal users -- LinkedIn employees -- via Enterprise Enrollment for iOS devices, and via Google Play’s alpha testing functionality and the developer console API. So it's not like they are sending the code without testing, and it appears that at any time, an internal user can torpedo a particular release candidate, so that what they end up with at the end of the week might be the same thing they had at the end of last week.

This still has a bunch of holes, just as any continuous integration process does, but at least by staging a 3 hour limit on things, they avoid falling into the trap that Google and Apple have leapt into willingly, where "it takes as long as it takes" to do integration acceptance testing.

In particular, both Google and Apple engage in reactionary testing paradigms. They build tests based on bugs they've previously encountered (because they are in fact able to test for those, since they've been well characterized during the process of being fixed), and stack them on top of all the previous tests.

This results in an ever-growing set of tests that test for regressions, but which do not test for correct behaviour of the products, overall. Instead, it lets you know when you've encountered a bug which you have previously encountered.

Further, since the testing is unbounded (and in fact, will stop the build process at Apple or Google by throwing a stick into the bicycle wheel of progress -- an event which is called "closing the tree", necessitates the existence of a "tree sheriff" role to deal with automated closures of the tree, and fails to automate the back-out of code leading to failure -- it leads to flaky tests.

The flaky tests come about because there's a human involved in making the decision, and in structuring the situation that way, with an unbounded closure interval -- practically bounded only by people showing up in your office (Apple) or open plan desk/cubicle (Google) and breathing down your neck -- there's a strong encouragement toward flaky tests, and there's a strong tendency do disempower the "tree sheriff" in favor of getting the expensive engineers back to work. And because of this, it's very hard to deep dive into flaky tests.

So we are left with the situation that flaky tests are both tolerated (as long as they are not "too flaky" -- or in Google-speak -- as long as they do not exhibit "too much 'jank' when run"), and the flaky tests do not get cleaned out eventually because the set of tests that you run are not pruned occasionally to run in bounded time, and if you try to do a deep dive to actually resolve the flakiness, you get the disapproval of your peers.

So a bounded time is a good thing, if you insist on having continuous integration, but it doesn't necessarily fix the other problems with continuous integration, and it doesn't fix the fact that most testing in organizations where engineers are involved in "agile methods", such as "Scrum Runs", where the primary goal is code base stabilization, rather than forward progress on the product for 2/3rds or more of the engineers time... well, combine that with an iterative process and it's a recipe for engineers who don't know about testing writing a lot of useless tests, because you are moving the goalposts on them iteratively anyway.

So they've done something relatively innovative, but it's probably not innovative enough. And it's probably an interesting experiment, but I would be wildly surprised if other organizations adopted their framework.

P.S.: The other problem with iterative models, particularly constant integration iterative models, is that you tend to only ever do evolutionary things, and never revolutionary things. There's not always a drunkards walk that gets you "from where we are" to "someplace new and fantastic". There are saddle points, and once you are in a saddle point, an iterative model will not get you out.

Comment I practically guarantee you... (Score 4, Insightful) 153

I practically guarantee you...

The problem is with a long or int (32 bit) value having its address passed in for a time_t (64 bit) value.

As long as the number is positive, it appears to work, but if it goes negative (and given that most of the people setting it to that date are West of GMT, it *will* go negative), then the underflow blows all the adjacent bits in the next 32 bit word over.

And it appears that something important was there. This will likely be a problem for the code after 19 January 2038, if that's the case.

This is why there should be strong type enforcement set in the compiler settings, to make sure it doesn't compile if you have this kind of bug in your code.

This should be a trivial fix, but it's pretty clear that you could fix the problem on your own by temporarily disconnecting the battery and/or letting the battery drain (which would likely take a very long time). So take it into your local Apple store and be done with it.

Comment Less than zero is a valid timestamp (Score 0) 153

The thing that bothers me about all of the summaries I've read, is that a timestamp less than zero (which is Jan 1 1970) is still valid - otherwise how would you represent dates before 1970???

I don't know what is going on but a timestamp being merely "less than zero" seems alone to not be a problem, it's how some other part of the system is dealing with this timestamp. Perhaps someone somewhere in the system frameworks shifted from a timestamp (which is really a double internally in iOS) to some kind of large unsigned int?

Comment This would be fairly radical actually (Score 1) 182

I'm not sure about Australia or the US or EU or wherever someone might live, but in Canada no-one is obligated to accept Cash for anything. A Constitutional Amendment so stating would actually mean a fundamental change in how business and debts are settled.

Which is why I don't believe this Amendment will get anywhere at all in Oz.

Comment Doesn't Matter ... Game Outcome is Final. (Score 0) 136

You know, this is important and everybody wants any Sporting Contest to be fairly refereed, and that includes issues with the Game Clock.

However, the Referees made a decision. Regardless of whether they were technically correct or not, the mechanism for applying rules to a Game is unambiguous; whatever the Officials decide is final once the game is declared "over".

You can do things under an appeal like remove the result from standings, or even award a win, but all that depends on whatever rules the game was played under and whether an appeal is even allowed, and what redress the rules provide for under that appeal, after the game was decided by the Officials.

Games have been decided this way since forever, and regardless of whether the Time Code on the Replay Video was correctly or incorrectly interpreted, the Officials make a rule and that's that. Appeal if it's allowed, or not, but there is no going back and complaining it was done wrong. And very important games have been settled this way since forever, and in some cases a "bad call" gives the winner an undeserved victory.

It's part of Sport. Get over it (Lord knows, as a Sports Fan, I have had to, many times).

Comment Two Seconds (Score 1) 564

Just take two seconds after you get routing directions up to zoom out and verify it's going about where you want to go.

I've driven in Iceland before and it's impossible to not go to Reykjavik if you pay even the least attention to signs, or just look at the map where you can see where Reykjavik is in relation to where you are driving.

I really like using Waze to guide me, not even by giving directions (which I often ignore) but just to see what roads are around me while driving so I can quickly adjust pathing to something that makes more sense.

One gripe I have with all modern nav systems is that I really wish I had a lot more control over the routes - like "avoid highway if possible" or "Your traffic predictions are always wrong, do not believe their lies". At least Apple Maps gives you three different routes to choose from, that's a nice start but I'd like to be able to guide it further.

Comment Re:The U.S. is much more civilized (Score 1) 40

I find it interesting to see how Europeans get so testy whenever any other country is mentioned. Seems like you are projecting quite a bit there!

This post should make you happy since it only talks about Europeans, even only the failings, unlike the ability of Americans to consider a bigger picture.

Oops! Ha Ha, just did that to goad you further obviously. If you don't want buttons pressed you may not want to wear them on your sleeve.

Slashdot Top Deals

Make headway at work. Continue to let things deteriorate at home.