Slashdot videos: Now with more Slashdot!

View

Discuss

Share

We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).

An anonymous reader writes "Patrick Wyatt, one of the developers behind the original Warcraft and StarCraft games, as well as Diablo and Guild Wars, has a post about some of the bug hunting he's done throughout his career. He covers familiar topics — crunch time leading to stupid mistakes and finding bugs in compilers rather than game code — and shares a story about finding a way to diagnose hardware failure for players of Guild Wars. Quoting: '[Mike O'Brien] wrote a module ("OsStress") which would allocate a block of memory, perform calculations in that memory block, and then compare the results of the calculation to a table of known answers. He encoded this stress-test into the main game loop so that the computer would perform this verification step about 30-50 times per second. On a properly functioning computer this stress test should never fail, but surprisingly we discovered that on about 1% of the computers being used to play Guild Wars it did fail! One percent might not sound like a big deal, but when one million gamers play the game on any given day that means 10,000 would have at least one crash bug. Our programming team could spend weeks researching the bugs for just one day at that rate!'"

CanadianSchism writes "I've been in the public sector for the past 6 years. I started off doing my work study in web design and a bit of support, eventually going through the interview process to fill in a data processing technician post, and getting the job. The first four years of my work life were spent in various schools, fixing computers, implementing new hardware, rolling out updates/ghosting labs, troubleshooting basic network and printer problems, etc. I was eventually asked to work on the administrative information systems with an analyst, which I've been doing for the past 2 years. That's consisted of program support, installing updates to the pay/financial/purchasing/tax/energy systems, taking backups on SQL servers, etc. I've never had the opportunity to take time for myself, and jump back into my first love: programming. I've picked up Powershell books (have two here at the office), but haven't gotten anything down yet, as there are always other projects that come up and whittle my attention to learning a language down to zilch. This new year will see a change in that, however. I'll be setting aside an hour every day to devote to learning a new language, in the eventual hope that I can leave this company (take a sabbatical) and hop into the private sector for a few years. My question to you all is, what language should I start with, to learn and get back into the principles of programming, that will help me build a personal portfolio, but will also lend to learning other languages? At this point, I'm not sure if I'd like to make/maintain custom applications, or if back-end web programming would be more interesting, or any of the other niches out there."

Several readers sent word that the Perl programming language turned 25 today. In his commemorative post at the Perl Foundation's website, mdk wrote,
"So what does the future hold for Perl? Well I don't have a crystal ball but I cannot see the language fading from usage in the next quarter century, the truth of the matter is that even though there are languages that can do some of the things that Perl does, some of them do some things better, others do things Perl wasn't designed for, there is no language that has been designed to do the things that Perl is very good at doing. No language in the current scripting languages seems to have the flexibility, maturity and extensibility of Perl. The main power of Perl has always been its ability to quickly adapt, and be adapted, to suit purposes. ... The greatest challenges we will face for Perl is a shifting end-user base that will become more reliant on devices that are feature focused but crippled in application choice, the rise in mobile devices will continue and Perl will need to evolve to work with that. A better challenge for us to face would be the integration with electronically aware, and connected devices and systems, the apocryphal internet of things, in this Perl could be a powerful tool. I also believe that the more we see a divergence of language uses in the other scripting languages the more they will face issues in their core designs, issues that Perl avoids due to its malleable nature, what some believe is the crippling factor for Perl is likely to be its saving grace as it has the power and flexibility to cope with the shifting goalposts of an increasingly technologically reliant world."

hypnosec writes "The Worldwide Web Consortium (W3C) has announced that it has finalized the definition of HTML5 and that it is ready for interoperability testing. HTML5 hasn't been given the status of standard yet but it is feature complete now, giving developers a stable target to develop their web applications. The W3C said in the announcement 'HTML5 is the cornerstone of the Open Web Platform" and that it provides an environment which can utilize all of a device's capabilities like videos, animations, graphics and typography. The HTML5 specifications still have a long way to go before they hit the Recommendation status. HTML5 will have to go through a round of testing that looks specifically into interoperability and performance after which time it will be given a Candidate Recommendation title."

An anonymous reader writes "I run a small dev shop focused on web development, based in Europe. For the past six years we've had lots of successful projects with clients from CEE, Western Europe and the U.S. One of our main clients was based in the U.S. We started working for them in 2008, while they were a 'promising start-up' and everything went smoothly until they were bought by a multinational corp. We couldn't be happier to work for such a big player in the market, andwe even managed to get by with huge payment delays (3-4 months on a monthly contract), but now, after more than two years working for them, I have the feeling we're getting left out. We have six-month-old unpaid invoices and we're getting bounced between the E.U. and U.S. departments every time we try to talk to them. What can a small company do to fight a big corporation that's NASDAQ listed and has an army of lawyers? They've been getting a lot of bad press lately so I don't think that will scare them either."

itwbennett writes "In an official document that is both 'confidential' and publicly available on Oracle's website, the company lays out its cloud policies. Most of the policies follow industry standards, but then there are a few that should give customers pause. Like the one that allows Oracle to turn off access to accounts in the event of a dispute or account violation."

First time accepted submitter Uzuri writes "I'm soon going to have the experience of interviewing an individual to be my direct supervisor. I have in mind several things to ask already, especially since I also have the strange position of working as a technical person in a non-technical office and want to be able to be certain that the interviewee understands exactly what that means without coming off as hostile or condescending. What sort of questions would you ask/have you asked the person who was to be your boss? What sort of tells would you look for? What's out of bounds?"

jppiiroinen writes "It seems that Nokia is slowly killing existing applications for their Linux based N9 mobile phone which are available through their store. As a developer who has published paid (and free) apps, it appears after their final blow of killing the support for paid applications in China, where the main revenue came from, there is not any means to make money, and no reason to maintain apps anymore. What this means also for the end-users: no premium apps, like Angry Birds. There was no heads-up or anything, just a single email without any means to make a complaint. Nokia, So Long, and Thanks for All the Fish." Also being discussed at Maemo.org.

Picking up work abandoned around Postgres 8.2, a patch recently hit the PostgreSQL 9.3 branch that adds SQL-92 automatically updatable views. For many common cases, you will no longer have to write hairy triggers to fake UPDATE support (e.g. if you have a view that hides a few internal columns). Limitations currently include only supporting views with at most one table in the FROM clause. This complements the under-advertised INSTEAD OF trigger support added in 9.1.

Via Planet KDE comes news that the videos from the 2012 Qt Developer Conference are available on YouTube. This joins the slides released in late November. It looks like there's some pretty interesting stuff in there.

First time accepted submitter MrBeeudoublez writes "Honored by a Google Doodle, Ada Lovelace is the first computer programmer. From the article: 'Ada's life as a member of British society (first as the daughter of Lord Byron, and later as the wife of the Count of Lovelace), brought her into contact with Charles Babbage, whose concepts for mechanical calculating machines (early computers) she took a great interest in. Ultimately, her work on explaining Babbage's design for the Analytical Engine resulted in her being credited as the first true computer programmer in history, even if the computer she programmed for was not actually built until 2002.'"

CowboyRobot writes "Dr. Dobb's has an editorial on the problem of using return values and exceptions to handle errors. Quoting: 'But return values, even in the refined form found in Go, have a drawback that we've become so used to we tend to see past it: Code is cluttered with error-checking routines. Exceptions here provide greater readability: Within a single try block, I can see the various steps clearly, and skip over the various exception remedies in the catch statements. The error-handling clutter is in part moved to the end of the code thread. But even in exception-based languages there is still a lot of code that tests returned values to determine whether to carry on or go down some error-handling path. In this regard, I have long felt that language designers have been remarkably unimaginative. How can it be that after 60+ years of language development, errors are handled by only two comparatively verbose and crude options, return values or exceptions? I've long felt we needed a third option.'"