Thursday, November 10, 2011

Steam has been 'pwned'. Security is everybody's business. Be smart.


A hacker, or hackers unknown have broken through security measures at Valve, defaced the Forums, and obtained a copy of a Steam database that lists encrypted credit cards, as well as usernames, and hashed/salted passwords. Okay this is bad.

But I bet you Gabe is thanking his lucky stars that they didn't choose to store Steam user passwords in plaintext in their database. Let this be a warning to anybody else out there; Don't ever store anything important plaintext in your database. Ever.

Friday, October 21, 2011

Skype is now a Microsoft product.


The Skype client for Windows is written in Delphi. So now that Microsoft owns and operates Skype, they are now customers of Embarcadero, owner of Delphi, the world's greatest software development tool.

Of course, given the corporate culture at Microsoft, I expect the rewrite to 100% ".net" to take them about 1 year. As of November 2012, I will probably have to amend my statement, to say that, from its inception until recently, Skype for windows was written in Delphi. Now it's written in .... something else.

Wednesday, October 12, 2011

Delphi Online Conference - "CodeRage 6"

The information-packed online developer conference that is specific to Delphi and C++ Builder users, starts next week. Register here for CodeRage 6.

I personally enjoy chatting online with other Delphi developers as we listen to great presentations about the latest in Delphi-specific tools and techniques, and ways to write better applications using the new features in Delphi XE2. I'm personally most interested in FireMonkey (FMX), the new framework that made its debut appearance in XE2, which allows you to write cross-platform applications that run on Windows, Mac, and some day other places (probably Linux, if the roadmap hasn't changed).

Saturday, July 23, 2011

Cool Delphi Answer: The Vigenère cypher as a code sample.

I would like to draw your attention to this answer on StackOverflow, where Andreas Rejbrand, a noted Delphi coder, has implemented for your pleasure, the classic Vignere cipher, a notable historical algorithm in cryptographic history because it resists casual attempts to decrypt it much better than ancient simple-substitution cyphers.

As a challenge, Andreas has asked anybody who wants to, to try to crack an example bit of text that has been encrypted using this cypher. Since you know the algorithm, and it's a historical algorithm, the most wonderful part of this answer is that I hope someone takes him up on this, and learns a bit about cryptography by trying to crack this cipher. Andreas has offered 100 SEK for the winner.

I consider it an epic mini-hack, and a nice bit of community on StackOverflow. As well, I consider that putting such effort into building a Delphi answers sub-community on StackOverflow is one of the brilliant things that can help new Delphi users take hold and begin to grow into competent (and eventually expert) Delphi developers. And that is the answer to the problem I wrote about yesterday.

I think Delphi is cool. And Delphi programmers are the coolest.

Friday, July 22, 2011

Is being a Delphi Developer career suicide?

A very smart guy that I have worked with in the past said to me yesterday, that the time he spent working on a project written with Delphi was tantamount to career suicide. I have little to no external evidence to prove him wrong, and yet I believe he could not be more wrong.

Let's try to understand his perspective first, though. From his perspective, C# and Java and C++ all have a large number of jobs up on all the major job websites. And if Delphi truly remains (in my opinion) a secret weapon, that developers can use to gain an advantage, how come so little software is written with it? Okay, Skype for Windows is written in Delphi. But none of the other versions of Skype (for your phone, or your mac) are written with Delphi.

I see a vicious circle-of-perceptions. The circle goes like this: There are no delphi jobs because there are no delphi developers because there are no delphi books because there is no market for delphi books because there are no delphi jobs because there are no delphi developers..




And there are barriers to entry, and network effects. New developers coming out of school have a number of barriers to entry with Delphi, including the fact that both Visual Studio and Java are essentially free to learn. The language-popularity network effect is viciously effective, here.

So how is Delphi going to survive against Visual Studio (Express is free) and Java (Eclipse and Java are totally free)? My friend's answer is simple; It isn't going to. In fact, you could argue, it's already statistically irrelevant. It's popular to quote the TIOBE list for that purpose. Now being #14 (Delphi) and #16 (Pascal) on the TIOBE list means that Delphi is, in general about as obscure as Lisp, and RPG ILE. And in fact, I notice there are more jobs out there for RPG LE developers then for Delphi developers, in most cities.

But writing off Delphi on such a flimsy basis would be a shame, in my view. I believe that the real cost of writing software is, and always will remain, the salaries of the people, and that tools that make those people work better, are worth buying. Not only is it worth buying an IDE, it's worth buying a profiler, and components, and other tools, if they act as "force multipliers" that make you more productive. Delphi is a great tool. Its merits do not grow less important, when less people use it. So what does mass-popularity mean, anyways?

I guess Delphi fans consider themselves a bit avant-garde, rather than behind-the-times. But which are we really? Delphi is a great tool for lone-wolf developers, and even if the corporate use of Delphi died out, single-man-shops would remain a significant Delphi user base. Probably millions of people worldwide. And yet, there might be a million people still modifying their Visual Basic 6.0 apps, and half a million people keeping CA-Clipper based or Excel-spreadsheet based custom apps running, just barely.

Let's face it; Corporate adoption of Delphi is important to everybody who uses Delphi. I would like to see a renaissance of Delphi corporate use. I'd like to see an end to corporate attrition away from Delphi. If you search for jobs involving Delphi on major job sites, you'll find fully 50% of the mentions of Delphi are from companies that are shifting away from Delphi. I know of several places in my city, that have major products that were built in Delphi, that have moved away from Delphi in the last five years. The perception of Delphi being "a fading away thing" drove the decision in many cases, more than the technical merits of a rewrite of a Delphi app in C# or Java.

I don't want my friend's pronouncement about Delphi to be true. But I'm looking to the future of Delphi, beyond Delphi XE, to change that. I believe Delphi is on the brink of a renaissance. A new level of functionality would help. But the thing that Delphi needs most of all is better documentation, and tutorials, and needs to encourage new user adoption by having more cheap or free training materials. These barriers to entry are surmountable. The new user experience in Delphi XE is not as simple and easy to get started in as Delphi 7 was. I think that those who love Delphi and want to grow the community, so that Delphi usage goes up in corporations and at startups, need to focus on the new-user's out of box experience. I am going to write a series of posts on what I think can be done.

I'm also going to play with the Delphi Welcome Page, and make my own version that is friendly for new users. I'll also record some screen-casts with New User Tutorials and post them on here. Here's my homework for you Delphi fans; Go make a tutorial video and post it on your blog. Explain why Delphi works for you, and why it solves problems that make it worth your while to learn a tool that other people are dismissing because it's not C#, and it's not Java, and it's not C++.

To survive, being awesome is not enough. The best way to save the future for Delphi is to make sure it's easy for people to learn it, and get up to speed. I think that a new big-fat-book, that covers as much ground as the Mastering Delphi or Delphi Developers Guide books did, is needed. I think about 500 tutorial videos are needed. I think that a lot of creative pricing and promotion is needed. The Delphi Starter edition was a great idea, and I heartily approve of it. I'm excited and positive about Delphi's future. But I think it's time to confront the elephant in the room; Delphi is neither dead nor dying, and it's not in the top-ten on TIOBE either. If you need to feel better by putting something else down; Feel bad for the SmallTalk folks. SmallTalk was supposed to be the biggest thing ever, and now at #48 on the TIOBE index, it's down there below COBOL and APL.

You know what's career suicide? COBOL and SmallTalk are career suicide. Except, I bet if you're really good at either one of them, you'd have more offers than you knew what to do with. The world is a big place. The internet is large. Guess what. Being in the top ten isn't necessarily going to be that great for your career either. I know you can get some big money these days working on RPG ILE and COBOL. Any takers?

Tuesday, July 12, 2011

64-bit Delphi Preview.


This has been up for a little while on the Embarcadero Delphi web page, but I am sure there are people who are interested in knowing more about the future of 64 bit delphi.

If you're willing to sign up for the Preview Beta, and you get accepted to the Beta, you can try the 64 bit Delphi compiler today! Check it out here on Embarcadero's website. According to the website, it's not guaranteed that all who apply will get in. A video is available at the website link where Embarcadero’s David Intersimone takes you for a tour of the Delphi 64-bit compiler.

Thursday, July 7, 2011

Delphi open source component: TComPort




The TComPort component was originally written by Dejan Crnila, it was modified a bit by other people, including me, among others. It didn't need much tweaking, other than a bug fix here and there, and support for new Delphi versions as it came along. The latest version 4.11b is available on SourceForge here.

Like a lot of developers who need to do serial communication, I started using Turbo Power's very capable AsyncPro product, which is still alive, and doing well. I have said some negative things in the past about AsyncPro, because the complexity in it mixed poorly with the complexity in my products, and when I had to debug things, I found it really hard to debug AsyncPro. But I should introduce a policy here on Delphi Code Monkey; I intend to publically do penance for stupid things I have said in the past. AsyncPro is a fabulous component set, and nothing negative I have said in the past should be held as more correct than the simple fact that lots of people use, and still use AsyncPro, and are happy with it.

Nevertheless, as a person who believes strongly in the "smaller is beautifuller" concept, almost to an absurd degree, and who has found that the less code I put in my application, the less my application breaks in horrible ways, I still prefer TComPort for the cases where I need to do serial communication in a delphi app.

TComPort seems like exactly what I needed for my purposes. So what were my purposes? I wrote applications that did the following things:

1. Talk to industrial or scientific or laboratory equipment, over an RS-232 or RS-485 link. Some of this equipment including Programmable Logic Controllers, using a common protocol called "Modbus RTU", or simple Ascii (text based) serial protocols, some with, and some without checksums. For modbus capable PLCs, I wrote a descendant component that does Modbus client communications, for Delphi, that can talk to a wide range of industrial and process control, and scientific equipment that implements this protocol.





2. Talk over a direct cable link, or a modem link, to equipment at a remote site. This is incredibly powerful. One application I wrote in the mid 1990s had dialup remote control of an emergency power grid that could be remotely activated by the power utility company in a major midwestern US city, whenever the grid needed additional capacity.





Here are things that I didn't need TComPort to do, things that would make AsyncPro a better choice than TComPort:

3. I did not need a full featured "video terminal emulator" that did fifteen different terminal emulations, including a reliable VT-52, or PC ANSI terminal emulation. You might need this, if you had to connect to an old computer system that provided serial terminals.

4. I didn't need to use the file transfer protocols from the BBS era, that include XModem, and ZModem.

Back in the DOS and BBS days, long before the Internet, those of us who used to "go online" used to do so using DOS programs called "Terminal programs", and plastic boxes called "modems", that let your plain old phone line talk at incredibly high speeds, between 300 and a few thousand bits per second. Just about everything that you could do in Telix, you can do in AsyncPro. AsyncPro (formerly from TurboPower, now open source) is better than TComPort, if you need a full featured video terminal emulator, or x/y/zmodem file transfers. If you still wanted to write a Telix for Windows in Delphi, Async Pro would be perfect for you.

So having given AsyncPro its due, let me proceed to why I like TComPort:

A. Small, Fast, Light.
B. Simple thread and event model.

One common place that serial ports still show up these days is in the IT world. Sometimes you might have a network router, or VPN box, that has a serial terminal that you might want to talk to. At one of my old workplaces, we had a building alarm system that had a serial port cable. We logged the alarm activity on our servers, using a little capture program, originally in VB, which I rewrote in Delphi.
Just because.

If you want to drop a component on a form, and talk through a serial port, check it out. Your programs can remotely interact with, control, or supervise a wide variety of equipment out there. You could even attempt to write the Auto-Dialer that figured so prominently in the 1980s movie War Games. Please don't hack our national electrical grids though, or I will have to hunt you down and give you a wedgie. Also the CIA and FBI might want to talk to you. Be good. Thanks.

If you have problems with this component, you can talk about it on the forums on sourceforge, and we'll try to help you out.

I could use a little help getting the component working again in C++Builder, so if you're a C++Builder expert out there, please check in with me. We need you.