Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror
×

Comment Grim Dawn (Score 1) 177

If PoE interests you (and it should, if ARPG is your thing), also check out Grim Dawn, made by Crate. I've been part of the Kickstarter process and even their "rough" betas have blown Diablo 3 away. Ok, that sets the bar too low... Even their betas are fun, stable, immersive and have good content.

Comment Re:FB2K FTW (Score 1) 400

Man, the one time I actually have a real use for mod points and I don't have any. You've hit the button on the head there. I've had Foobar2k pushed at me for years and in all that time, it still sucks royally. It's a UX nightmare. Winamp is small, fast, just works. Audacious does a good job on Linux, but needs some work on win32 -- and I'm really hoping to get the motiviation & time to do it. Because balls man. Winamp. WTF.

Comment Educated != smarter (Score 1) 482

All that proves, really, is that people are able to regurgitate information more accurately, probably, in part, driven by econimically-guided procreation: people who have been able to do this better are getting better jobs, have better prospects, etc, etc, etc.

Common sense, on the other hand, remains rare -- and I would argue it's rarer than it's been in the past. You'd think that the average populace would be more difficult to dupe -- but they're not. You'd think that the number of people who can see through an obvious farce would rise -- but I'm sure most would agree that this isn't the case.

Of course, sometimes it's really difficult to tell the difference between actual stupidity and self-centered ignorance. When another person impacts your life negatively through some act which just seems blatantly stupid, is it actually just because they are too selfish to take anyone else into consideration? Quite likely.

Comment Re:Can't Go Backwards (Score 1) 736

Don't confuse UI with task accomplishment.
I totally hear you about a hanging background thread (which sucks for the user), but, let's imagine that background threads are properly handled (and perhaps even timed-out, as would be for network traffic). So a good example is this: imagine an application which presents you with a list of tasks to accomplish for the day. It starts up blank and asynchronously fetches your tasks for the day from a remote source. Now, the reason you want an indeterminate progress feedback mechanism (eg daisy loader) is because, on the day when you have no tasks, you need to know the difference between the app being busy and actually having completed its work, presenting your empty task list. This kind of thing is easy to accomplish, say, with jQuery where you have an asynchronous call which has two functions given to it: one when the call completes properly, and one which is called when the asynchronous call fails. BOTH should implement some kind of feedback that the operation has "completed" (ie, hide the daisy loader), and, of course, the failure path should inform the user that the operation failed -- and perhaps offer a mechanism for retry.
But, for this discussion, the only interesting parts are:
1) show the daisy loader
2) perform asynchronous call
3) when the asynchronous call completes or fails, hide the loader.

Comment Having done a few progress indicators... (Score 1) 736

I can tell you that it's not always easy to give back a progress indicator which is meaningful to the user. The user wants to know (generally), how *long* is left, time-wise, where most progress-bars indicate how much of the overall activity is left to complete. The OP actually makes this point quite clear.

And therin lies the proverbial rub: if you're, for example, unpacking a small app, but you send some kind of statistic or registration information over a network at the end, even though that last sub-action is small (in comparison to the overall process), you're at the mercy of network latency, so that could be anything from 5 seconds to whatever network timeout has been set.

Trying to give a useful ETA on a progress bar / percentage feedback: now that's a challenge. Just for chuckles, check out http://code.google.com/p/fappy -- it's a playlist generator written in python. I wanted some kind of ETA on there, but I'll be the first to admit that it takes a while to settle and the ETA may rise -- because you can only make future predictions based on past experiences so, whilst you may have zipped through the first 1000 of 20000 files really quickly, you could hit a bunch of super-fragmented files, wait longer on disk IO, and have your ETA rise.

So the short answer is that it's quite easy to provide a progress bar displaying, essentially, a percentage of completed tasks within a procedure. But tying a progress indicator to an ETA or making sure that all percentage points come at the same time cost -- less than trivial.

Comment Re:Can't Go Backwards (Score 1) 736

Actually, they (and daisy loaders) do have a point, when used correctly: they're an indicator to the user that the process hasn't STALLED, even though the time to completion is unknown.
I'd rather have one of these than an app that looks like it's hung. So, apparently, would most users: even an indeterminate progress "meter" makes users happier to wait for a process to complete -- even to wait longer!

Comment Yeah, it sucks for freelance devs with a clue too (Score 1) 257

I've been trying to pick up some ad-hoc / freelance work, much like the OP. Freelancer.com has been a complete waste of time. It's obvious from the bids on projects that a lot of the bidders don't have a clue and are just trying to get in the cheapest bid -- but even when I have been the cheapest bid, I have yet to actually be contacted or acknowledged. The sad thing is that I'm happy to do the work at a cheaper rate just for some extra $$ and I'm pretty good at what I do: I have 12 years software dev experience in a range of languages and tech. My current job is good and I have recruiters scrabbling to get me on to the next thing -- but none of that appears to matter on these sites.
I've actually given up with trying to find work there -- it's a complete waste of time for me as a dev. It appears to be a complete waste of time for the people looking for devs too :/

Comment Re:Cowboys not welcome, IMO (Score 1) 1051

Ok, so now I've spent the time reading all of the posts (thanks, I have nothing better to do with a toddler in the house :/) and I still have to stand by the statement that Linus, whilst often blunt to the point of traumatic, is no liar. He's quite honest.

The apology only comes AFTER being chewed out -- the initial stand from Mauro is erring on the side of stating that PA is broken (which it may be, but that's not the point here; the point is that Linus has made it very clear in the past that kernel changes cannot break userspace because when they do, users (desktop and server) as well as userland developers lose confidence in the base system. It's bad for everyone.

I don't think you fully understand the terms "cowboy" and "rock star" and just how detrimental these people are. Sure, I only described "cowboy" for you, but since you're so intent on full completion, let me remind you that rock stars don't work well in teams because they believe their stuff is simply better than everyone else's. Often, they may even be right -- which causes a feedback loop that just makes the situation worse. I've had to maintain a rock star's code before -- sure, it was good, functional, fast. It was also incredibly difficult to read and when I fixed a flaw which became quite obvious, the tantrum that ensued made sure that I would never helpfully commit to that code base again. I had to interface with that code so when I found routines that were of interest to me, I would often rip them out, make them readable, fix any edge cases and keep them in my repo -- instead of just committing the (imo) higher quality code back to the original author.

Regarding your last comment: I still think that the linked mail from Linus (whilst quite blunt) is not completely off-kilter. A project of any reasonable size requires a technical lead who understands the project and its requirements and the unbreakable rules that come with those requirements. Linus is that guy and I think he does a reasonable job of it considering the size and requirements of the project. It's his leadership which gives me confidence in the kernel -- because it's no longer a hackthing: it's actually a solid work now (and has been for quite a few years; bear in mind where Linux came from) and Linus is putting that ahead of the feelings of the contributors -- which, at the end of the day, is good for the user and, eventually the contributors.

Mauro is properly apologetic *after* being chewed out. And I believe that (a) he won't make a mistake like that again and (b) he will be a useful member of the contributing team, having learned that the rules that have been established for the project are, in fact, immutable. He's no arch-villain, in the same way that Linus is no hero: Mauro made a mistake, got flamed and learned. Linus is just doing his job.

Comment Re:Cowboys not welcome, IMO (Score 1) 1051

I think you misunderstand the terms "rock star" and "cowboy". These terms are not reserved for people who are merely proud of what they do - they are labels for people who code without thought of consequence, e.g. considering who has to clean up when the next gem they excrete breaks everyone else's work.

As for the second part, I have to admit that I only bothered to read Linus' response. Whilst I think many people know of Linus' volatile nature, I don't think he's a liar or apt to fabricate a fanciful scenario. Just reading his post paints the picture that this dev was not apologetic for breaking user-space, but instead tried to blame PulseAudio (ok, everyone likes to blame PA). Also his comments on code quality and clarity WRT the submitted patch were on target (again, assuming he's not lying about the patch contents).

So either you're saying Linus fabricated the whole thing or perhaps you read something out of order?

Comment At least Linus stands up for the USER. (Score 1) 1051

No, instead, it actually reminds the world that Linux is not a hodge-podge of arbitrary decisions and that there is a strong leader who is determined to make sure that the desktop doesn't suffer because of kernel development. If Steve Ballmer crapped out his staff for making a service pack that broke existing application functionality, it would actually raise him a notch in my book.

I say good on Linus. He's stressed before that the userland is not a place to break stuff because it negatively affects the entire world's perception of the kernel and the OS distributions built around it. This chap made a mistake and didn't have the guts to admit it and back off. So perhaps he (and other cowboy programmers) will learn that actually the USER is the MOST IMPORTANT PART OF THE SYSTEM.

Slashdot Top Deals

The key elements in human thinking are not numbers but labels of fuzzy sets. -- L. Zadeh

Working...