Become a fan of Slashdot on Facebook


Forgot your password?
Take advantage of Black Friday with 15% off sitewide with coupon code "BLACKFRIDAY" on Slashdot Deals (some exclusions apply)". ×

Comment Re:Autonomy fails when the unexpected happens (Score 1) 397

Software can be written to even handle unanticipated events. In many pieces of software, unanticipated stuff happens all the time (time outs, services returning garbage, network failures).

What do you when something unanticipated happens? You come to a stop in an empty lane and activate your warning lights? Or maybe you keep driving, even with that wierd noise you keep hearing and see if it goes away?

Software could do the same, and probably do it with better info than you have.

Comment Re:Hard to direct to specific locations (Score 1) 397

There's these things called maps. You could click on where you want to go, and the car can drive you to the nearest location there that is accessible by road.

When parking, it could display you a nice image of where to go or park next (maybe even just display you a map of your surroundings gathered with radar or whatever). Click where you want to park, or better yet, where you want to be dropped off.. who wants to wait for your car to park, it can do that by itself.

This stuff simply is not impossible. AI will approach that of humans soon enough, and it will be able to drive cars...

Comment Re:CVS or Subversion (Score 1) 325

Unfortunately, most people that use Git, used to use SVN. They think that merges solve all problems, as that was the only tool available in SVN.

In Git however, you have two tools to solve your problems. Rebase and Merge. Rebase is just as fundamental a tool as Merge, so one of the first things you should learn is the difference between the two. Once you learn how it works, you'll look at merges as something evil unless it was a merge to integrate something in the main branch.

One of the most compelling reasons to use Rebase is that it makes it possible to make all your merge commits fast-forward commits. What this means is that even though something took 20 days to build in a branch, once you put it back into the main branch you can make it appear as if all the work happened instantaneously and was added as one nicely packed change right on top of the current state of the main branch.

Comment Re:CVS or Subversion (Score 1) 325

I spotted the mistake. You have branches that last 3 months. In our team we have branches that last at most 1 sprint (two weeks) and often much shorter than that.

A branch should be something short-lived. Split that 3 months of work into much much smaller pieces that can be added to the develop or master branch without breaking anything (if necessary with a functionality switch). In a code base that is not somekind of tangled mess, small refactorings and changes are the way to go. Often we have several refactor and clean-up commits (that donot change functionality) before actually implementing a feature (which after the refactorings and cleanups is often trivial).

No version control system is gonna save you from the merge or rebase problems you'll have after working in your own little bubble for 3 months.

Comment A script.. (Score 1) 212

#! /bin/bash

# stop on errors
set -e

scriptname=$(basename $0)

# lock it
exec 200>$pidfile
flock -n 200 || exit 1
echo $pid 1>&200

# Rest of code

RSYNC_OPTIONS="-ah --no-inc-recursive"


if [ -d "$MOST_RECENT" ]; then
if [ -f "$SRC/.snapshots-filter" ]; then
    FILTER="--filter='merge .snapshots-filter"

CMD="$RSYNC $RSYNC_OPTIONS $FILTER --exclude=.git --exclude=.snapshots $LINK_DEST \"$SRC/\" \"$SNAPSHOTS/.temp/\""

mkdir -p "$SNAPSHOTS/.temp"
eval $CMD
touch "$SNAPSHOTS/.temp"

function moveBackup {
    if [ -d "$1" ]; then
        if [ $(((`date +%s` - `stat --format %Y "$1"`) / 60)) -ge $4 ]; then
            if [ -d "$2" ]; then
                if [ ! -d "$3" ]; then
                    mv "$2" "$3"
                    rm -rf "$2"
            mv "$1" "$2"

moveBackup "$SNAPSHOTS/around 3 months ago" "$SNAPSHOTS/around 6 months ago" "$SNAPSHOTS/around 9 months ago" 259110
moveBackup "$SNAPSHOTS/around 1 month ago" "$SNAPSHOTS/around 2 months ago" "$SNAPSHOTS/around 3 months ago" 86310
moveBackup "$SNAPSHOTS/about 15 days ago" "$SNAPSHOTS/about 23 days ago" "$SNAPSHOTS/around 1 month ago" 33030
moveBackup "$SNAPSHOTS/about 7 days ago" "$SNAPSHOTS/about 11 days ago" "$SNAPSHOTS/about 15 days ago" 15750
moveBackup "$SNAPSHOTS/about 3 days ago" "$SNAPSHOTS/about 5 days ago" "$SNAPSHOTS/about 7 days ago" 7110
moveBackup "$SNAPSHOTS/24 hours ago" "$SNAPSHOTS/about 2 days ago" "$SNAPSHOTS/about 3 days ago" 2790
moveBackup "$SNAPSHOTS/8 hours ago" "$SNAPSHOTS/16 hours ago" "$SNAPSHOTS/24 hours ago" 870
moveBackup "$SNAPSHOTS/4 hours ago" "$SNAPSHOTS/6 hours ago" "$SNAPSHOTS/8 hours ago" 270
moveBackup "$SNAPSHOTS/2 hours ago" "$SNAPSHOTS/3 hours ago" "$SNAPSHOTS/4 hours ago" 90

if [ -d "$SNAPSHOTS/1 hour ago" ] ; then
                mv "$SNAPSHOTS/1 hour ago" "$SNAPSHOTS/2 hours ago"


chown --reference="$SRC" "$SNAPSHOTS"
chown --reference="$SRC" "$MOST_RECENT"

Comment Re:That again? (Score 1) 382

That's because "import wheel" in Python means something different than the similarly written statement in Java.

In Java an import written like that imports only one specific class. In Python it means import everything defined in the wheel "package". You can do the same in Java: import wheel.*

That syntax however is frowned upon, as it makes it less explicit about what you are actually using, and more assumptions must be made to understand the code. Did that class come from "wheel" or did it come from "stoneage", "car", "steam" or "yarn" ?

Anyway, contact me again when a Python snippet can actually survive being send by email.

Comment Re:It's not that great (Score 1) 414

The semi-colon's mean I can split up a long line of code in nicely lined up parts with just the enter key. Without them, I might be changing what the code does, or I'd need to fix all the parts and add somekind of continue operator.

The fact that those semi-colon's are there is one of those things that makes Java more readable. I don't have to guess that a line will be continued or not (see Javascript). Making it optional just serves to confuse future readers of the code - that's why Java makes these mandatory. You can leave them out, but then you're code means something else.

This and the fact that Java often only gives you one option to write something is exactly what makes the language so readable. Try explaining that though to the Scala / Groovy / Clojure / Hip++ crowd however... they seem convinced that the number of keystrokes it what dictates development speed... perhaps I should sell them Dvorak keyboards...

Comment Re:must fail (Score 2) 298

It is good practice to throw exceptions for even fatal errors. What they've missed however is to add information to the exception about the error (the stuff you propose they should log).

Somewhere way up the call stack you have a catch all exception handler, which is responsible for logging the exception -- so it is not necesarilly the caller who logs this. If the caller cannot handle the exception, it should just leave it and let it bubble up.

This way there's no need to duplicate logging code in every small little function that can't handle certain inputs.

MSDOS is not dead, it just smells that way. -- Henry Spencer