Wednesday, February 8, 2012
Feb 14: Happy Birthday Delphi
Embarcadero are having a Birthday Party celebration for Delphi's birthday on February 14th. Sign up here.
Friday, February 3, 2012
The Keyboard Cult (Delphi Code Monkey Edition)
Programmers use keyboards all day long, and so we tend to get exercised about our favorite, and least favorite keyboards. I have been on a bit of a "keyboard" jag lately, as I have been through a series of keyboard disappointments, and I'm confident that keyboards, if done better, might do more to help programmers than any other innovation in computing. This is big.
Jeff Atwood rather famously blogged some time ago about the Keyboard Cult in programming. His article mentions the various types of key technologies available (dome versus keyswitch), layouts (curved ergonomic, standard, and oddball ergonomic units), and various things. I'd like to talk about how important keyboards are to doing our job, as programmers, no matter what language we use. My history, as a Borland Barbarian and Turbo Pascal geek from the late 80s and early 90s factors in here, and so I'll call this the "Delphi code monkey" edition of the Keyboard Cult discussion. I am a programmer of a certain age, I've been writing code for more than 27 years, and I've been getting paid to write code for the last 24 of those.
I'd like to go back through the keyboards that mattered most to me, in the years I have been a software developer, and point out what made each one great, or not so great.
Pre-Computer Era: The IBM Selectric Typewriter
I learned to touch type in Grade 9, on an IBM Selectric II electric typewriter. My typing teacher taught us the classic typing techniques, that were taught to her, back when she started on a manual typewriter. Starting with home keys (F and J), we did simple "move away from home row and back" exercises. The first day started with "F-R-F" and "J-U-J" repetition exercises. This helped us acquire muscle-memory knowledge of the QWERTY layout, and after the basic layout is comitted to muscle memory, we would do drills to increase speed, all the while "not looking at the keyboard". If the keyboard had in fact been blank, with some color codes we probably would have learned more quickly,once the initial fear of looking away from the keys had been overcome. By the end of grade 9 I could touch type at 60 WPM. I am currently around 120 WPM, while writing code, and up to 150 WPM while composing English sentences in a word processor. I do not think at all about what I'm doing while I'm typing, any more than a pianist has to think about where the black key for C#/D-flat that is two octaves above middle-C is. I bet that if you put all the names of the notes on a piano it would only slow down a beginning pianist, and that the best approach would be to put dots where your home left and home right hand position are, and to let your brain learn by muscle memory and repetition where everything is.
The letter keys, and most of the punctuation keys on the computer keyboard in front of you right now are mostly the same as this IBM Selectric, that is, if you live in the USA or Canada. The only punctuation move that I can see is that the shifted 1 key is an Exclamation point on PC keyboards, but it's a plus-minus (±) sign on this IBM Selectric layout. There are no cursor keys. There is no escape key, and the only modifier key (Ctrl,Alt,Meta,Command) is the Shift key.
The first time I used a computer keyboard, I had to learn about even more additional keys that only appear on a computer. When I was in grade 8, a classmate brought in a "TRS-80" microcomputer. Everybody thought that the red key labelled "Break" was hilarious. "Look at me, I'm BREAKing your computer" the kids yelled at Steve, as they pressed the Break key. We didn't know what it did.
8-bit Microcomputer Era: The Commodore 64
I learned to code on a Commodore 64, in BASIC and Assembler, using a keyboard, without a mouse.
Basic programming was done using line oriented program entry without a text editor, IDE, or anything other than the 4K ROM BASIC that shipped hard-wired into the computer, and which came up automatically when you turned it on.
The version control system we used was called "save early, and save often, and don't re-use the same file-name twice", and in practice, it looked like this:
I still long for a return to a simpler keyboard. If you do too, you might be interested in the spiritual successor of the Early Hacker Keyboards. One of the best is called the Happy Hacking Keyboard, and if you yearn for simpler days, this might be keyboard nirvana for you. There are also a whole raft of "tenkeyless" keyboards, including the venerable IBM Model M Compact.
If you are in fact still a Commodore 64 hacker at heart, then what you really want is the all new Commodore 64 X, from the reborn "Commodore USA". This isn't just a keyboard that looks like a Commodore 64, it's an actual modern PC capable of running Windows 7 or Linux, shoved inside the loaf-of-bread size plastic box.
88 and 101 Key PC Keyboards (1987-1994)
Like most people who had 8 bit computers, I bought my first PC clone in the late 1980s. I never owned an IBM-branded computer, I used a series of clones, and their clone keyboards, and I adjusted each time to slight differences in the keyboard layout. At some point after the introduction of the IBM PC AT, powered by an Intel 80286, the backslash key moved to the position above the enter key, and stayed there, and a lot of programmers like me got used to that position, because the backslash is the path separator in DOS, and the special-character-in-a-string-literal code in the C family of programming languages. I did not love, and did not hate any of these keyboards. When Windows 3.1 came out, I did not immediately add "using a mouse" to my programming techniques. I used DOS-based IDEs to write software, and became proficient in the use of hundreds of keyboard shortcuts. `Shift+F8` meant "Run until return" in Turbo Pascal, and is still the default shortcut for that feature in Delphi today.
Certain elements of this keyboard layout are no longer optional, but are essential to my ability to write code now. A standard IBM PC AT cursor key arrangement (the inverted-T format), the location and size of the insert/delete/home/end/pageup/pagedn keys above the cursor keys, the location of delete, backspace, Escape, enter, backslash, ctrl, alt, shift, and almost every other key, must not change, I will become quickly frustrated. My brain is no longer capable of adjusting to changes in keyboard layouts, just as my eyes have a harder time adjusting to different focal lengths.
Ergo Keyboards Era(1994-2012)
When the original Microsoft Natural Keyboard came out, I became a devoted owner and user of the keyboard. I owned several, and they lasted me almost ten years. In the end, Microsoft makes the best curved-top ergonomic keyboards out there, and my favorite keyboard, which is no longer available, is the original 1.0 version of the Microsoft Natural Keyboard. The current "Model 4000" has normal PC cursor keys. These are the most acceptable keyboards that I have found that accomplish several objectives for me:
1. Help me type quickly and accurately.
2. Help me work all day without getting uncomfortable, or getting RSI, or carpal tunnel syndrome.
The Ugly Truth
I wish there was something out there that was better, but for the life of me, I can't find it. I am unwilling to learn a completely new way of inputting data (such as DataHand) or radically altered ergonomic keyboards like Kinesis.
Mechanical keyboards help me with problem #1 above (speed,accuracy) because the click sound is a form of positive feedback. However, they do not help me with the RSI/soreness problems that conventional keyboards have. What I wish I could find is something that combines the mechanical feel of a good clicky Cherry MX keyswitch, with an ergonomic layout.
Think Different?
The other alternative I'm considering is using an Apple aluminum keyboard. The thing about them, is that the small tenkeyless (No numeric keypad) ones are almost as small as my much beloved Commodore 64, or the happy hacking keyboard, and the low-travel design of the low profile keyboard, might just be less stressful on my hands then even the ergonomic keyboards from Microsoft. Right now I'm typing on my macbook pro, and I notice that my hand position is nearly as relaxed and open as the position I can maintain on my computer at work, where I've got a Microsoft Natural Keyboard Pro that is about 10 years old.
What do you think?
I'd like to hear from you, what you like and what you expect from a keyboard you use all day to code.
Jeff Atwood rather famously blogged some time ago about the Keyboard Cult in programming. His article mentions the various types of key technologies available (dome versus keyswitch), layouts (curved ergonomic, standard, and oddball ergonomic units), and various things. I'd like to talk about how important keyboards are to doing our job, as programmers, no matter what language we use. My history, as a Borland Barbarian and Turbo Pascal geek from the late 80s and early 90s factors in here, and so I'll call this the "Delphi code monkey" edition of the Keyboard Cult discussion. I am a programmer of a certain age, I've been writing code for more than 27 years, and I've been getting paid to write code for the last 24 of those.
I'd like to go back through the keyboards that mattered most to me, in the years I have been a software developer, and point out what made each one great, or not so great.
Pre-Computer Era: The IBM Selectric Typewriter
I learned to touch type in Grade 9, on an IBM Selectric II electric typewriter. My typing teacher taught us the classic typing techniques, that were taught to her, back when she started on a manual typewriter. Starting with home keys (F and J), we did simple "move away from home row and back" exercises. The first day started with "F-R-F" and "J-U-J" repetition exercises. This helped us acquire muscle-memory knowledge of the QWERTY layout, and after the basic layout is comitted to muscle memory, we would do drills to increase speed, all the while "not looking at the keyboard". If the keyboard had in fact been blank, with some color codes we probably would have learned more quickly,once the initial fear of looking away from the keys had been overcome. By the end of grade 9 I could touch type at 60 WPM. I am currently around 120 WPM, while writing code, and up to 150 WPM while composing English sentences in a word processor. I do not think at all about what I'm doing while I'm typing, any more than a pianist has to think about where the black key for C#/D-flat that is two octaves above middle-C is. I bet that if you put all the names of the notes on a piano it would only slow down a beginning pianist, and that the best approach would be to put dots where your home left and home right hand position are, and to let your brain learn by muscle memory and repetition where everything is.
The letter keys, and most of the punctuation keys on the computer keyboard in front of you right now are mostly the same as this IBM Selectric, that is, if you live in the USA or Canada. The only punctuation move that I can see is that the shifted 1 key is an Exclamation point on PC keyboards, but it's a plus-minus (±) sign on this IBM Selectric layout. There are no cursor keys. There is no escape key, and the only modifier key (Ctrl,Alt,Meta,Command) is the Shift key.
The first time I used a computer keyboard, I had to learn about even more additional keys that only appear on a computer. When I was in grade 8, a classmate brought in a "TRS-80" microcomputer. Everybody thought that the red key labelled "Break" was hilarious. "Look at me, I'm BREAKing your computer" the kids yelled at Steve, as they pressed the Break key. We didn't know what it did.
8-bit Microcomputer Era: The Commodore 64
I learned to code on a Commodore 64, in BASIC and Assembler, using a keyboard, without a mouse.
Basic programming was done using line oriented program entry without a text editor, IDE, or anything other than the 4K ROM BASIC that shipped hard-wired into the computer, and which came up automatically when you turned it on.
The version control system we used was called "save early, and save often, and don't re-use the same file-name twice", and in practice, it looked like this:
SAVE "PROG032",08
I still long for a return to a simpler keyboard. If you do too, you might be interested in the spiritual successor of the Early Hacker Keyboards. One of the best is called the Happy Hacking Keyboard, and if you yearn for simpler days, this might be keyboard nirvana for you. There are also a whole raft of "tenkeyless" keyboards, including the venerable IBM Model M Compact.
If you are in fact still a Commodore 64 hacker at heart, then what you really want is the all new Commodore 64 X, from the reborn "Commodore USA". This isn't just a keyboard that looks like a Commodore 64, it's an actual modern PC capable of running Windows 7 or Linux, shoved inside the loaf-of-bread size plastic box.
88 and 101 Key PC Keyboards (1987-1994)
Like most people who had 8 bit computers, I bought my first PC clone in the late 1980s. I never owned an IBM-branded computer, I used a series of clones, and their clone keyboards, and I adjusted each time to slight differences in the keyboard layout. At some point after the introduction of the IBM PC AT, powered by an Intel 80286, the backslash key moved to the position above the enter key, and stayed there, and a lot of programmers like me got used to that position, because the backslash is the path separator in DOS, and the special-character-in-a-string-literal code in the C family of programming languages. I did not love, and did not hate any of these keyboards. When Windows 3.1 came out, I did not immediately add "using a mouse" to my programming techniques. I used DOS-based IDEs to write software, and became proficient in the use of hundreds of keyboard shortcuts. `Shift+F8` meant "Run until return" in Turbo Pascal, and is still the default shortcut for that feature in Delphi today.
Certain elements of this keyboard layout are no longer optional, but are essential to my ability to write code now. A standard IBM PC AT cursor key arrangement (the inverted-T format), the location and size of the insert/delete/home/end/pageup/pagedn keys above the cursor keys, the location of delete, backspace, Escape, enter, backslash, ctrl, alt, shift, and almost every other key, must not change, I will become quickly frustrated. My brain is no longer capable of adjusting to changes in keyboard layouts, just as my eyes have a harder time adjusting to different focal lengths.
Ergo Keyboards Era(1994-2012)
When the original Microsoft Natural Keyboard came out, I became a devoted owner and user of the keyboard. I owned several, and they lasted me almost ten years. In the end, Microsoft makes the best curved-top ergonomic keyboards out there, and my favorite keyboard, which is no longer available, is the original 1.0 version of the Microsoft Natural Keyboard. The current "Model 4000" has normal PC cursor keys. These are the most acceptable keyboards that I have found that accomplish several objectives for me:
1. Help me type quickly and accurately.
2. Help me work all day without getting uncomfortable, or getting RSI, or carpal tunnel syndrome.
The Ugly Truth
I wish there was something out there that was better, but for the life of me, I can't find it. I am unwilling to learn a completely new way of inputting data (such as DataHand) or radically altered ergonomic keyboards like Kinesis.
Mechanical keyboards help me with problem #1 above (speed,accuracy) because the click sound is a form of positive feedback. However, they do not help me with the RSI/soreness problems that conventional keyboards have. What I wish I could find is something that combines the mechanical feel of a good clicky Cherry MX keyswitch, with an ergonomic layout.
Think Different?
The other alternative I'm considering is using an Apple aluminum keyboard. The thing about them, is that the small tenkeyless (No numeric keypad) ones are almost as small as my much beloved Commodore 64, or the happy hacking keyboard, and the low-travel design of the low profile keyboard, might just be less stressful on my hands then even the ergonomic keyboards from Microsoft. Right now I'm typing on my macbook pro, and I notice that my hand position is nearly as relaxed and open as the position I can maintain on my computer at work, where I've got a Microsoft Natural Keyboard Pro that is about 10 years old.
What do you think?
I'd like to hear from you, what you like and what you expect from a keyboard you use all day to code.
Monday, January 30, 2012
Firemonkey: Promise and Limitation
Firemonkey is amazing, when considered as a platform with a future. As a product, as it ships, it's a strange mix of odd capabilities, and unusual gaps.
For example, it's cool that everything in Firemonkey HD (formerly 2D) can be rotated and scaled. The scaling is practically useful, more than the rotation, but who knows... Maybe rotation of 90 degrees can be useful for charts or other diagrams, or in combination with animations, but I have yet to see animation used in business applications for much.
Scaling may not matter to you today, but if you have ever cared about supporting high-DPI displays in Windows, or on Mac, you need Firemonkey, not the VCL. The VCL will never be as High-DPI friendly as Firemonkey. It was a brilliant move to name Firemonkey "HD" instead of calling it "2d". The other mode in firemonkey is 3d, and so obviously the "HD" mode is 2 dimensional, but by explaining that the purpose was to be "high def" it very clearly reminds you that classic Win32+GDI is "non-high definition".
If by some chance an update to Firemonkey was to provide GDI+ back-ends on Windows, in addition to the current DirectX (win) and OpenGL (mac) back-ends, so much the better. The VCL can include GDI+ elements, such as the fine GDI+ based controls from TMS Software, but no complex VCL application I've ever written or ever will be able to write, will ever seamlessly blend GDI and GDI+, and support HIgh-DPI awareness, to my satisfaction. I've met people who claim to write Win32 applications that perfectly work at high-DPI values other than 96 DPI. I don't buy it though. Either their applications are ridiculously simple, or they have done a ridiculous amount of grunt-work to make it all work. Either way, it's hardly the low-friction "it just works" experience that Delphi users crave.
Firemonkey doesn't quite look native on Windows, or Mac, but it does provide a reasonably modern UI. It's a bold, impressive move, and it's clearly ahead of its time. The value proposition of "one app that runs natively on mac and pc, with differences between platforms either abstracted out by the framework, or IFDEFd when necessary" is convincing. And Pascal is a better language than C++, C# or java, for such an endeavor. Native code with a compile time code optimization is always faster than JIT. It's a no brainer. Delphi and C++ apps spend zero cycles doing JIT-code generation. Delphi and C++ Apps are compile time analyzed and compile time optimized, and compile time linked to strip out unused code. Delphi and C++ will always be faster and provide a smaller size application with less runtime to setup, or none (in Delphi's case). And Delphi will always be a simpler, easier to learn and more orthogonal language. It will also be less feature-complete than C++. It will fit in your brain better than C++, although C++ 2011 is an amazing language, it's still full of complexity and warts that make me none to eager to work all day using C++.
There are huge challenges ahead for Firemonkey on Mac. If you think about it, Firemonkey offers a way onto Mac for Delphi fans, and as a combo Mac and Delphi fan, I'm very happy about that. However, there is a principle of "least common denominators" that is the bane of the cross-platform developer's existence. Mac OS X is built on Cocoa+Objective-C frameworks, and anybody who doesn't write their app on Mac, using native Cocoa, will not be able to use the new frameworks. So, for example, just try to make an app with Firemonkey, and have it use OS X Lion's new document model. If you try to write an app and have it accepted as good enough to count as a Mac app instead of a "lame port of a windows app", you need to observe the platform conventions and rules as set out by Apple, as implemented in their Document Model. The easiest way to be sure you're following all those rules is to write your app in Objective-C with the Cocoa frameworks that implement it all for you. Frankly, if all you want is just a Mac app and you don't need it to run on Windows, then it's a no brainer; Learn objective-C and cocoa. But if you (like me) would like to write an app and spend a bit more effort to get it working on both Windows and Mac, then Apple doesn't care to help you.
The only real alternatives I see to Delphi + Firemonkey, for native application development, are QT and C++, or other similar frameworks, like wxWidgets and C++. There is also an open-source Pascal flavor, "FreePascal", and an IDE project "Lazarus", but if you thought Firemonkey looked "beta", well, then, I can only describe Lazarus and its LCL frameworks as "alpha level". They provide something less than VCL 1.0 level experience, and although I hope that they grow and improve in the future, they are of little interest to me, aside from one thing; Lazarus IDE actually runs natively on Mac OS, Windows, and Linux. For that alone, I should give a little nod to the geeks who built this thing and made it open source; Way to go, good work. But I'm not all that interested in LCL, and I don't think it's nearly as promising as "Firemonkey" and Delphi.
I have been developing some test applications, and trying to learn Firemonkey on Windows. I am disappointed that you can't skin the non-client areas of a window, or the Main Menu area. I'm disappointed that there is no ActionList or ActionManager yet, and that as yet there is no printing support in Firemonkey, however I am confident that they will add all those things, and much more, and that by the time Firemonkey reaches a "2.0" designation, it will hopefully be at least at the point where most of us will be seriously considering starting our next big application in Firemonkey.
I plan to write a serious text editor for Mac + Windows in firemonkey, and add printing support to it once Firemonkey supports it. I plan to investigate Document Framework classes that will run atop both Mac and Windows versions of Firemonkey, and offer a native document experience on both platforms, including operating system search and indexing, spotlight and quick preview on mac, and start-menu and task-bar integration on Windows. Just because you're cross platform doesn't mean your users will let you get away with inferior platform integration. Delphi should let you go deep, and now, wide, at the same time.
The future is Delphi on Mac OS, iOS, Windows, and hopefully some day, Android and Linux. I'm not even going to mention Windows Phone, or Blackberry, because they are dead already they just don't know it yet. Oh wait, I did mention them. Forget I mentioned them, they're dead.
For example, it's cool that everything in Firemonkey HD (formerly 2D) can be rotated and scaled. The scaling is practically useful, more than the rotation, but who knows... Maybe rotation of 90 degrees can be useful for charts or other diagrams, or in combination with animations, but I have yet to see animation used in business applications for much.
Scaling may not matter to you today, but if you have ever cared about supporting high-DPI displays in Windows, or on Mac, you need Firemonkey, not the VCL. The VCL will never be as High-DPI friendly as Firemonkey. It was a brilliant move to name Firemonkey "HD" instead of calling it "2d". The other mode in firemonkey is 3d, and so obviously the "HD" mode is 2 dimensional, but by explaining that the purpose was to be "high def" it very clearly reminds you that classic Win32+GDI is "non-high definition".
If by some chance an update to Firemonkey was to provide GDI+ back-ends on Windows, in addition to the current DirectX (win) and OpenGL (mac) back-ends, so much the better. The VCL can include GDI+ elements, such as the fine GDI+ based controls from TMS Software, but no complex VCL application I've ever written or ever will be able to write, will ever seamlessly blend GDI and GDI+, and support HIgh-DPI awareness, to my satisfaction. I've met people who claim to write Win32 applications that perfectly work at high-DPI values other than 96 DPI. I don't buy it though. Either their applications are ridiculously simple, or they have done a ridiculous amount of grunt-work to make it all work. Either way, it's hardly the low-friction "it just works" experience that Delphi users crave.
Firemonkey doesn't quite look native on Windows, or Mac, but it does provide a reasonably modern UI. It's a bold, impressive move, and it's clearly ahead of its time. The value proposition of "one app that runs natively on mac and pc, with differences between platforms either abstracted out by the framework, or IFDEFd when necessary" is convincing. And Pascal is a better language than C++, C# or java, for such an endeavor. Native code with a compile time code optimization is always faster than JIT. It's a no brainer. Delphi and C++ apps spend zero cycles doing JIT-code generation. Delphi and C++ Apps are compile time analyzed and compile time optimized, and compile time linked to strip out unused code. Delphi and C++ will always be faster and provide a smaller size application with less runtime to setup, or none (in Delphi's case). And Delphi will always be a simpler, easier to learn and more orthogonal language. It will also be less feature-complete than C++. It will fit in your brain better than C++, although C++ 2011 is an amazing language, it's still full of complexity and warts that make me none to eager to work all day using C++.
There are huge challenges ahead for Firemonkey on Mac. If you think about it, Firemonkey offers a way onto Mac for Delphi fans, and as a combo Mac and Delphi fan, I'm very happy about that. However, there is a principle of "least common denominators" that is the bane of the cross-platform developer's existence. Mac OS X is built on Cocoa+Objective-C frameworks, and anybody who doesn't write their app on Mac, using native Cocoa, will not be able to use the new frameworks. So, for example, just try to make an app with Firemonkey, and have it use OS X Lion's new document model. If you try to write an app and have it accepted as good enough to count as a Mac app instead of a "lame port of a windows app", you need to observe the platform conventions and rules as set out by Apple, as implemented in their Document Model. The easiest way to be sure you're following all those rules is to write your app in Objective-C with the Cocoa frameworks that implement it all for you. Frankly, if all you want is just a Mac app and you don't need it to run on Windows, then it's a no brainer; Learn objective-C and cocoa. But if you (like me) would like to write an app and spend a bit more effort to get it working on both Windows and Mac, then Apple doesn't care to help you.
The only real alternatives I see to Delphi + Firemonkey, for native application development, are QT and C++, or other similar frameworks, like wxWidgets and C++. There is also an open-source Pascal flavor, "FreePascal", and an IDE project "Lazarus", but if you thought Firemonkey looked "beta", well, then, I can only describe Lazarus and its LCL frameworks as "alpha level". They provide something less than VCL 1.0 level experience, and although I hope that they grow and improve in the future, they are of little interest to me, aside from one thing; Lazarus IDE actually runs natively on Mac OS, Windows, and Linux. For that alone, I should give a little nod to the geeks who built this thing and made it open source; Way to go, good work. But I'm not all that interested in LCL, and I don't think it's nearly as promising as "Firemonkey" and Delphi.
I have been developing some test applications, and trying to learn Firemonkey on Windows. I am disappointed that you can't skin the non-client areas of a window, or the Main Menu area. I'm disappointed that there is no ActionList or ActionManager yet, and that as yet there is no printing support in Firemonkey, however I am confident that they will add all those things, and much more, and that by the time Firemonkey reaches a "2.0" designation, it will hopefully be at least at the point where most of us will be seriously considering starting our next big application in Firemonkey.
I plan to write a serious text editor for Mac + Windows in firemonkey, and add printing support to it once Firemonkey supports it. I plan to investigate Document Framework classes that will run atop both Mac and Windows versions of Firemonkey, and offer a native document experience on both platforms, including operating system search and indexing, spotlight and quick preview on mac, and start-menu and task-bar integration on Windows. Just because you're cross platform doesn't mean your users will let you get away with inferior platform integration. Delphi should let you go deep, and now, wide, at the same time.
The future is Delphi on Mac OS, iOS, Windows, and hopefully some day, Android and Linux. I'm not even going to mention Windows Phone, or Blackberry, because they are dead already they just don't know it yet. Oh wait, I did mention them. Forget I mentioned them, they're dead.
Saturday, December 17, 2011
Quick Sort : With Hungarian Dance
This is a great visualization of the Quick Sort algorithm.
Most programmers could write a bubble sort. But I wonder how many could write an insertion sort, quick sort, or heap sort, without benefit of Wikipedia, or StackOverflow, or google, or any internet "crutches". If you understand it well enough to draw it out visually, you can write it.
Next time you have a hard programming problem, I recommend you step away from the keyboard, and try a pencil and paper. And if that doesn't work..... Maybe do a little dance.
Most programmers could write a bubble sort. But I wonder how many could write an insertion sort, quick sort, or heap sort, without benefit of Wikipedia, or StackOverflow, or google, or any internet "crutches". If you understand it well enough to draw it out visually, you can write it.
Next time you have a hard programming problem, I recommend you step away from the keyboard, and try a pencil and paper. And if that doesn't work..... Maybe do a little dance.
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).
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).
Subscribe to:
Posts (Atom)