Forum bot - Help please

Hi,
I am searching for help with creating a forums bot. I don't intend to make a spambot! I just want to make a web application in PHP with database which should help me with creating and replying for my post on many forums. I am registered on about 50 forums where I post links to my files and I do it daily. But it take me about 2 hours to do one post. So I want to creat an application where I put links to my files and some description and save it to database and then I want to create post with this content to all of the forums. Of course under my login name. So I am looking how are the spam or guestbook robots work so I could use code to built this application. Could someone help me?

Thanks.

Read More...

I Happen to Like Heroic Coding

I've been following Michael Abrash for more than 10 years now; he's one of my programming heroes. So I was fascinated to discover that Mr. Abrash wrote an article extolling the virtures of Intel's upcoming Larrabee. What's Larrabee? It's a weird little unreleased beast that sits somewhere in the vague no man's land between CPU and GPU:

[Larrabee] is first and foremost NOT a GPU. It's a CPU. A many-core CPU that is optimized for data-parallel processing. What's the difference? Well, there is very little fixed function hardware, and the hardware is targeted to run general purpose code as easily as possible. The bottom lines is that Intel can make this very wide many-core CPU look like a GPU by implementing software libraries to handle DirectX and OpenGL.

We know that GPUs generally deliver one or two more orders of magnitude more performance than a general purpose CPUs at the things they are good at. That's what I would expect for dedicated hardware devoted to a specific and highly parallizable task.

Michael Abrash has already attempted what most people said was impossible -- to build a full software 3D renderer that runs modern games at reasonable framerates. In other words, to make a general purpose CPU compete in a completely unfair fight against a highly specialized GPU. He's effectively accomplished that, and his company sells it as a product called Pixomatic:

In this three-part article, I discuss the process of optimizing Pixomatic, an x86 3D software rasterizer for Windows and Linux written by Mike Sartain and myself. Pixomatic was perhaps the greatest performance challenge I've ever encountered, certainly right up there with Quake. When we started on Pixomatic, we weren't even sure we'd be able to get DirectX 6 features and performance, the minimum for a viable rasterizer. I'm pleased to report that we succeeded. On a 3 GHz Pentium 4, Pixomatic can run Unreal Tournament 2004 at 640�480, with bilinear filtering enabled. On slower processors, performance is of course lower, but by rendering at 320�240 and stretching up to 640�480, Unreal Tournament 2004 runs adequately well -- even on a 733-MHz Pentium III.

Pixomatic is documented in an excellent series of Dr. Dobbs articles. It's fascinating reading; even though I know zero about assembly language, Michael's language of choice, he's a fantastic writer. That old adage about the subject not mattering when you have a great teacher has never been truer.

I remember trying out Pixomatic briefly four years ago. Those CPUs he's talking about seem awfully quaint now, and that made me curious: how fast is the Pixomatic software renderer on today's CPUs? My current box is a Core 2 Duo (wolfdale) running at 3.8 GHz. So I downloaded the Unreal Tournament 2004 demo (still fun, by the way!), and followed the brief, easy instructions provided to enable the Pixomatic software renderer. It's not complicated:

ut2004.exe -software

One word of warning. Be sure you have an appropriate resolution set before doing this! I was playing at 1920x1200 initially, and that's what the software renderer defaulted to. And here's the shocker: it was actually playable! I couldn't believe it. It wasn't great, mind you, but it was hardly a slideshow. I tweaked the resolution down to something I felt was realistic: 1024x768. I turned on framerate display by pressing ...

~
stat fps

... from within the game. This Pixomatic software rendered version of the game delivered a solid 40-60 fps experience in capture the flag mode. It ran so well, in fact, that I decided to bump up the detail -- I enabled 32-bit color and bilinear filtering by editing the ut2004.ini file:

[PixoDrv.PixoRenderDevice]
FogEnabled=True
Zoom2X=False
SimpleMaterials=True
LimitTextureSize=True
LowQualityTerrain=False
TerrainLOD=10
SkyboxHack=True
FilterQuality3D=3
FilterQualityHUD=1
HighDetailActors=False
SuperHighDetailActors=False
ReduceMouseLag=True
DesiredRefreshRate=0
DetailTexMipBias=0.000000
Use16bitTextures=False
Use16bit=False
UseStencil=False
UseCompressedLightmaps=False
DetailTextures=False
UsePrecaching=True

Once I did this, the game looked totally respectable. Eerily reminiscent in visuals and performance to the classic, early Voodoo and Voodoo 2 cards, actually.

(If you think this looks bad, check out Doom 3 running on an ancient Voodoo 2 setup. It's certainly better than that!)

The frame rate took a big hit, dropping to 30fps, but I found it was an uncannily stable 30fps. The only achilles heel of the Pixomatic software renderer is places with lots of alpha blending, such as when you fire a sniper rifle, obscuring the entire screen with a puff of muzzle smoke, or if you're standing near a teleportation portal.

Pretty amazing, right? It is!

And utterly pointless.

My current video card renders Unreal Tournament 2004 at the highest possible resolution with every possible quality option set to maximum, at somewhere between 200 and 300 frames per second. Despite the miraculously efficient assembly Abrash and Sartain created to make this possible at all, it's at best a carnival oddity; even the crappiest onboard laptop 3D (assuming a laptop of recent vintage) could outperform Pixomatic without even breaking a sweat.

We know that the game is far more enjoyable to play with a real GPU, on a real video card. And we're hip deep in real GPUs on every platform; even the iPhone has one. Perhaps Pixomatic made some business sense back in 2003, but it didn't take a genius analyst back then to see that it would make no business sense at all today. At the same time, I can't help admiring the engineering effort that went into building a viable 3D software renderer, something that seemed virtually impossible bordering on foolish.

In short, it will be possible to get major speedups from [Larrabee] without heroic programming, and that surely is A Good Thing. Of course, nothing's ever that easy; as with any new technology, only time will tell exactly how well automatic vectorization will work, and at the least it will take time for the tools to come fully up to speed. Regardless, it will equally surely be possible to get even greater speedups by getting your hands dirty with intrinsics and assembly language; besides, I happen to like heroic coding.

Ditto.

We'll have to wait and see if Intel's efforts to push GPU functionality into their x86 architecture makes any of this heroic coding more relevant in the future. Either way, it remains impressive.

[advertisement] Improve Your Source Code Management using Atlassian Fisheye - Monitor. Search. Share. Analyze. Try it for free!

Read More...

The Ugly American Programmer

On the internet, you can pretend the world is flat. Whatever country you live in, whatever language you speak, you have the same access to the accumulated knowledge of the world as every other citizen of the planet Earth. And a growing percentage of that knowledge can and should be available in your native language.

But I believe the rules are different for programmers. So much so that I'm going to ask the unthinkable: shouldn't every software developer understand English?

A wildly disproportionate amount of programming information is available in English. The overwhelming majority of programming languages use English keywords. By any metric you can possibly measure, English is the lingua franca of programming.

Now, In terms of cultural literacy and travel, presuming that everyone should speak English is a totally unacceptable attitude, the epitome of the ugly american.

But those rules don't apply to us.

We're not talking about normal everyday people. We're talking about programmers. Citizens of the internet. People who swear allegiance not to a country, but a compiler. Hackers have their own culture, their own norms and standards for literacy. Eric Raymond notes that functional English is required for true hackers:

As an American and native English-speaker myself, I have previously been reluctant to suggest this, lest it be taken as a sort of cultural imperialism. But several native speakers of other languages have urged me to point out that English is the working language of the hacker culture and the Internet, and that you will need to know it to function in the hacker community.

Back around 1991 I learned that many hackers who have English as a second language use it in technical discussions even when they share a birth tongue; it was reported to me at the time that English has a richer technical vocabulary than any other language and is therefore simply a better tool for the job. For similar reasons, translations of technical books written in English are often unsatisfactory (when they get done at all).

Linus Torvalds, a Finn, comments his code in English (it apparently never occurred to him to do otherwise). His fluency in English has been an important factor in his ability to recruit a worldwide community of developers for Linux. It's an example worth following.

Being a native English-speaker does not guarantee that you have language skills good enough to function as a hacker. If your writing is semi-literate, ungrammatical, and riddled with misspellings, many hackers (including myself) will tend to ignore you. While sloppy writing does not invariably mean sloppy thinking, we've generally found the correlation to be strong -- and we have no use for sloppy thinkers. If you can't yet write competently, learn to.

It's difficult to communicate this idea without feeling like an ugly American programmer. But it doesn't come from a nationality, or a desire to dominate the world. It's nothing more than great hackers collectively realizing that sticking to English for technical discussion makes it easier to get stuff done. It's a meritocracy of code, not language, and nobody (or at least nobody who is sane, anyway) localizes programming languages.

I received this email from Slawomir, a Polish programmer, a few months ago. He confirmed what I've always suspected and secretly believed -- but have been hesitant to say:

I just listened to Stack Overflow podcast episode 29 where you discuss localization of developer tools.

In my opinion there is no reason to translate developer tools and documentation.

I know many developers in Poland who prefer (as Joel mentioned) to get English documentation rather than Polish translation and the reason for that is that translations were not always accurate. Even Microsoft developer documentation was translated partially or with errors, so reading original English document was easier than English-Polish soup.

If everybody blogs and develops in English - our global repository of solutions and blog posts is much bigger and you have better chances of finding an answer to your problem.

Consciously choosing to switch from Polish to English reminds me why I gave up Visual Basic for C#, as painful as that was. These languages do exactly the same things -- and the friction of choosing the minority language was severe. I found reams of code and answers in C# whenever I searched, and almost nothing at all in VB.NET. I spent so much time converting code into VB.NET and introducing new bugs and errors in the process, along with countless language-only forks. This eventually stopped making sense to me -- as it would to any good programmer.

Advocating the adoption of English as the de-facto standard language of software development is simple pragmatism, the most virtuous of all hacker traits. If that makes me an ugly American programmer, so be it.

[advertisement] Improve Your Source Code Management using Atlassian Fisheye - Monitor. Search. Share. Analyze. Try it for free!

Read More...

Almost Perfect

I'll always remember WordPerfect as the quintessential white text on blue screen application.

For a period from about 1985 to 1992, WordPerfect was the most popular word processing program in the world on virtually every computing platform. I remember it well; the very concept of word processing was synonymous with WordPerfect.

And now I can't even recall the last time I encountered a WordPerfect document, much less anyone who still uses WordPerfect. The software is still limping along, barely, under the auspices of Corel corporation, as WordPerfect Office X4. I guess it's a testament to how quickly things change in the world of software; you can dominate the world for years, only to be relegated to little more than a dimly remembered footnote in computing history a decade later.

Perhaps that's why the online book Almost Perfect, which documents the rise and fall of WordPerfect, is such a gripping read. I clicked through, read the first chapter, read the second chapter, and ... I couldn't stop reading it!

Some of the story is predictable. WordPerfect, like many other companies at the time, never really made the transition from DOS to Windows. They didn't just bet on the wrong horse, they institutionalized a software culture that lived and died on character mode assumptions. That, plus an almost fanatical dedication to cross-platform parity -- even when the platforms they supported made little business sense -- makes the final outcome almost inevitable.

Still, there's something intriguing about the fledgling SSI corporation. For one thing, the entire business was run in an agile, almost by-the-seat-of-their-pants way. It's a bit of a David and Goliath story, how they clawed their way to success over so many formidable opponents by simply dedicating themselves to creating an excellent product, and cultivating a vibrant community around that product both inside and outside the company. But perhaps the best part is that the company was run by programmers:

We spent a lot of time in meetings going over what had to be in the product and how things should work. These decisions were made by the programmers, who sometimes had very heated discussions about what was needed. At times the three of us on the Board had to assume the role of referee. Some of the issues were very complicated, so by the time the arguments were finished and a decision was made, I usually had a headache.

It was somewhat unusual for a software company to let the programmers decide the future of its products. We were, however, a company founded and owned by programmers, where programmers were treated with an extra measure of respect. The marketing department was used primarily to sell products once they were developed, and only rarely did it get involved early enough to perform the traditional marketing role of identifying a need and defining a product to fill that need. At times this put us in the position of developing solutions before we identified problems, but it was hard to be too critical of the programmers when the company was so successful. To their credit, the programmers tried very hard to listen to our customers and to those of us in the marketing department. The programmers were smart and thoughtful and very good at protecting the best interests of the company. At times, however, they were prone to manipulate some of the data they received to fit what it was they wanted to do.

The story sort of fizzles out toward the end, as the author, W. E. Pete Peterson, is unceremoniously kicked out of the company just as WordPerfect Corporation begins to lose its hold on the market. Perhaps this is fitting: like WordPerfect itself, he doesn't go out with a bang, but a whimper.

At any rate, Almost Perfect is fantastic reading. Long out of print, it finds its own audience when self-published on the web. It's reminiscent of the very best early computer industry tales from one of my favorite books, Accidental Empires.

The book was also made into a documentary, Triumph of the Nerds. I recommend both highly.

I'm not sure if all the lessons from Almost Perfect are relevant today -- but some failure patterns are timeless, and I certainly admired the way SSI bootstrapped itself while letting the employees (and more specifically, the programmers) run the company.

[advertisement] Improve Your Source Code Management using Atlassian Fisheye - Monitor. Search. Share. Analyze. Try it for free!

Read More...