|
peterchen wrote: At worst, it also makes distribution GNOME-based software more of a user problem: "Works on my machine".
I think they're almost admitting that's a problem already. I have noticed that things don't work exactly the same on all distros already, even things that should work the same, only way to know for sure is to test on all of your supported distributions unfortunately.
|
|
|
|
|
Software development’s not quite the lawless and anarchic wild frontier people make it out to be. Developers today have seven decades of
practical experience of writing software under commercial pressures to draw on, and there are many insights that have been built up over that time that an aspiring young programmer needs to know. Check out this free ebook. You might learn something.
|
|
|
|
|
Generally the cowboy programmers have been weeded out since code cannot be maintained.
|
|
|
|
|
These are many of the basic principles I wish many of the people I've come across during my professional career would have understood.
At my last company, we were so bogged down with maintaining a failure of a code base that we didn't have the opportunity to change. It may have been too expensive to start from scratch, and the constant fixes prevented any real innovation. Basically, we had a losing product and there was no customer willing to pay what it would cost to fix the situation.
I have had coworkers with no desire or willingness to change. Here I am, exploring the latest technologies and innovating, and I am left unable to violate their turf, and so parts of the product remain in the stone age. They weren't only holding me back; they were holding the company back.
As far as learning while developing goes, I've not yet worked for a place that allowed for rapid learning to take place (I refer here to learning from mistakes, not learning new tech). Without the ability to test locally and without an environment that allows for all the pieces to be tested together, it can delay learning and both cause frustration and cost time/money.
And do I ever have some stories to share regarding communicating with other developers through code. Most developers I have worked with write code that the computer can understand (if the computer is very forgiving), but that was obviously built with no intention of having the code be understood by another developer. How easy is it to write a comment? To format your code? Most can't seem to manage these most basic tasks. Maybe it's hopeless to think they'll ever be able to write code that is simple, effective, and that can tolerate change well.
There are solutions to all of these problems, but far too few places implement them or even recognize the problems. And if you bring up the problem and even provide a solution, people are often so used to their comfort zone that they won't even let you fix the problem for them. I'm sure there must be places that have figured out the solutions; I suppose it's the luck of the draw whether or not you happen to end up at one of them (and probably also initiative to seek them out).
|
|
|
|
|
Finding a needle in a haystack is easy. When it comes down to it, needles are not hay. Finding one book lost among a million other books? That’s hard. The only reason such a thing as a library is possible is that it is a gigantic, life-sized, walk-in data structure, tuned for fast lookup. This post is about searching and sorting, two fundamental aspects of data processing, and what the library has to teach us about them. You could look it up.
|
|
|
|
|
I want to explore what happens when a statically linked program gets executed on Linux. By statically linked I mean a program that does not require any shared objects to run, even the ubiquitous libc. In reality, most programs one encounters on Linux aren’t statically linked, and do require one or more shared objects to run. However, the running sequence of such programs is more involved, which is why I want to present statically linked programs first. It will serve as a good basis for understanding, allowing me to explore most of the mechanisms involved with less details getting in the way. The exec's connected to the sys_execve....
|
|
|
|
|
So you just finished your most recent Arduino project and are hungry to build something new and impressive. Feeling confined by the Arduino's limited environment, peripherals, and power, you begin looking around for other options, but there are too many choices. There are microcontrollers from dozens of vendors in eight-, 16-, and 32-bit flavors, each requiring its own compilers and programmers, which could add up to a fortune. Is there no cheap and viable alternative for the little blue board that has stolen all our hearts? Enter the ARM Cortex M series of 32-bit microcontrollers... If we need that extra push over the cliff, you know what we do? Put it up to 32-bit.
|
|
|
|
|
One of the great tragedies of modern technical writing is that it has gotten so standard and boring. There is absolutely no reason for it. It does not make it clearer or easier to read, in fact it makes it worse in every way - less clear, less fun, less human. If you read actual great technical writing, it has humanity and humor. Pedantic and condescending. And so is the technical writing. (Warning: rough language.)
|
|
|
|
|
Head First Design Patterns had a pretty interesting writing style. They even have a few pages in the front of the book that describe why they use the writing style they do (basically, to trick your brain into thinking what you are reading is absolutely important, so you'll retain the information better).
|
|
|
|
|
The operating system is VxWorks. This is a classic microkernel. A modest guess is that the kernel is less than 10 Kilolines of code and is quite battle tested. In other words, this kernel is near bug free. The key here is isolation. We isolate different parts of the rover. There are certain subsystems which are outright crucial to the survival of the rover, whereas a scientific instrument is merely there for observation. Hence we can apply a nice fact, namely that only parts of our 2.5 million lines of code needs to be deeply protected against error. There will some parts which we can survive without. To Mars and beyond... the Erlang programmer's view.
|
|
|
|
|
Hopefully it doesn't get hacked, but it would be quite the news story if it did.
|
|
|
|
|
While there's overwhelming similarity between the operating systems in most cases, there are also a lot of differences. As you probe more into the differences, you find that they emerge from deep-seated disagreements. Some are disagreements over development methodology, some over deployment and usage, some about what's important, some about who's important, and some about which flavor of ice cream is superior. Just comparing the surface differences doesn't tell you anything; it's the deeper differences that both explain and justify why each group does things the way they do. You know what works on all of them? rm -rf *
|
|
|
|
|
BSD vs Linux is yet another of these sad (Beta vs VHS type) stories about an inferior technology winning.
|
|
|
|
|
The keyboard you think is the best will depend heavily on what you use it for. Whether you're gaming and need programmable keys, you're a productivity ninja who also needs programmable keys, you listen to music while working and want media keys, or you just like a trusty long-lasting keyboard that feels good and doesn't take up space, you probably have a suggestion. Well, we asked for them, and close to 600 nominations later, you told us what you thought. Unfortunately, we only have room for the top five... I love the Cherry MX Red tenkeyless action. What's your favorite keyboard?
|
|
|
|
|
only noobs use keyboards. i prefer Razer Nostromo + Razer Naga Epic + custom individual macros for each app over any keyboard xD
|
|
|
|
|
None of those keyboards really holds much advantage to me. I particularly hate ergonomic keyboards that aren't like "Microsoft Natural Keyboard Series". What tells me immediately that they are not really ergonomic is that the keys keep the standard key slant that dates back to when levers had to go from the keys to the strikers. Should have gotten rid of that design long ago, as well as the QWERTY layout. We are stuck with it now. See http://www.bestcovery.com/kinesis-advantage-contoured-keyboard[^]. There was also an interesting keyboard that was designed to be one handed: http://en.wikipedia.org/wiki/FrogPad[^]. It looks like the company is no longer arround . ALso, if I have a wireless keyboard, I want a trackpad on the keyboard so I can use the keyboard without a desk.
|
|
|
|
|
I would venture to say that most software developers have some sort of belief that they are just a regular programmer, but there exists out there some super programmers who actually do the difficult algorithms that control caches on hard drives and index search results for Google. Now, of course there are programmers writing code that does all kinds of complex things that you and I don’t understand, but how different are those programmers from the rest of us? What is the most difficult problem you have ever been asked to solve?
|
|
|
|
|
Vegeta: How can this be happening!? I am a super-elite! And he is just a low-level, common soldier.
|
|
|
|
|
Are geniuses just born with their brains wired differently? Or do their early experiences fashion a richer set of neuronal interconnections that let them view the world through a sharper lens? An outfit in San Francisco called “tenXer” has begun testing a service that aims to help people boost their mental accomplishments by up to tenfold—hence its name. That has made your correspondent wonder what distinguishes the truly talented from the journeymen of any trade. And what, if anything, the rest can do to improve their more menial lot. Don't mess with your brain, pal. It ain't worth it.
|
|
|
|
|
Software is a product of humans, humans exhibit defects as do their software. Microsoft software is no different. You can report issues on the Microsoft Connect site or to Microsoft Support directly. My recommendation is that if possible you should do both. Here's one developer's experience submitting bugs to Microsoft.
|
|
|
|
|
If you are programming in Visual Basic 6.0 and planning to move to Visual Basic .NET, then the Visual Basic 6.0 Code Advisor is for you. The Code Advisor for Visual Basic 6 is an add-in used to review your code to ensure that it meets predetermined coding standards. The coding standards are based on best practices developed by Microsoft to produce robust and easy-to-maintain code. You must be running Windows 98 or later, Internet Explorer 6.0 or later, and Visual Basic 6.0.
|
|
|
|
|
Has anyone tried to see if this tool actually helps a significant amount with migrating away from VB6 without doing a complete rewrite? eg suggesting fixes/changes for VB6 features the conversion wizard can't change automatically?
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, waging all things in the balance of reason?
Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful?
--Zachris Topelius
Training a telescope on one’s own belly button will only reveal lint. You like that? You go right on staring at it. I prefer looking at galaxies.
-- Sarah Hoyt
|
|
|
|
|
Dan Neely wrote: Has anyone tried ... this tool...
It's a trap! Run VB6 coders!
|
|
|
|
|
Meet in the middle (sometimes called split and merge) is a clever idea that uses caching to get efficient solutions. Much like divide et impera it splits the problem in two and then tries to merge the results. The benefit is that by using quite a bit of extra memory you can tackle problems of twice the size you could before. Now let's go through a few applications of the trick. The additional problems are the best part of the article.
|
|
|
|
|