It’s been a while, hasn’t it? Since I last posted on this blog we’ve passed not only into a new year but a new decade. I’ve made the transition to a new job — loving it so far, thanks for asking — bought a new, Android-based phone, and gotten engaged to my dearest Traci, among a whole slew of other (albeit more minor) life events. It is with utmost sincerity that I wish every one of you out there the best of fortune in the times to come.
Without getting too sentimental though, I thought I’d impart some useful technical tidbits while I wait for a particularly large SQL database to attach itself to my local server instance… Crap, it just got done while I was typing the previous sentence. No matter — onward to the more interesting stuff:
SQL Server
- Find out who’s connected to which databases on SQL Server with a query: (here)
- Regular expression evaluation in SQL Server queries requires OLE Automation to be enabled: (here)
- Determine the most expensive queries executed on a server: (here)
- Make sure variable data types in all your queries match the data passed in by your applications. Case in point, one of our websites here experienced a 10x improvement in response time after adjusting an NVARCHAR to a VARCHAR. If types are mismatched, SQL basically does not get a chance to utilize column indices, causing a potentially massive slowdown especially as table size grows. Another example comes from Stack Overflow: (here)
- The most efficient way to truncate the time from a DATETIME value: (here)
- Some simple DB optimization tricks: (here)
E-mail
- Attachments are included in the plaintext message stream as encoded Base64
- It is possible to send e-mail with all manner of HTML formatting, attachments, etc. at the lowest level by connecting to your SMTP server with a Telnet client and entering the proper commands: (here)
- Communication with POP3 servers via Telnet is even easier: (here)
.NET
- To open a file using its default application from .NET, use a System.Diagnostics.Process object, specifying the full path of the file you wish to open instead of an executable: (here)
- SqlDataReaders and DataTables fetch data much quicker on average than SqlDataAdapters and DataSets. If you only need to do a simple fetch operation, consider taking this route. It’s just as easy as using a DataAdapter, too: (here)
Miscellaneous
- If you need to test anti-virus capabilities on a system for whatever reason, the EICAR test file is a uniformly agreed-upon “sample virus” that will do no harm to whatever system it resides on. What’s more, you can create it yourself using a text editor: (here)
Hopefully my next update will come sooner than it did this time. Until then, be careful out there.
If you’ve been taken in by the Twitter craze and you happen to be toting around a netbook, you may want to check into some software written by Darren Yates by the name of Twextter. It appears he’s written it from the ground up to accommodate small (9-10″) netbook screens with a resolution of about 1024 x 600. Best of all, Twextter is cross-platform — it will run on any Linux system with GTK+ 2.0, as well as versions of Windows from 2000 Professional to the brand-new Windows 7.
Although the app is still in its beta phases, it looks very promising. The last update was posted March 26th, 2009, but I’m currently trying to get in contact with the author to see if he would be willing to open-source his creation (if he hasn’t already and I just can’t find it).
After months of deliberation on the subject, I finally decided to purchase my very own ASUS eeePC this past weekend. I managed to get my hands on the 1005HAB model in Midnight Blue. The 1005HAB is the “budget” model in the 1005HA line, but that doesn’t bother me all too much. No Bluetooth, but then I wouldn’t use it, and it takes up battery life. The HAB packs a smaller 3-cell battery too, but it’s always upgradable, and I’m satisfied with the 3-4 hours I get out of it now anyway. All in all, I’m very satisfied with my purchase and I’d buy it again if given the chance to do it all over.
Now — like any good techie, it’s time to tinker with it. Straight out of the box, I doubled the RAM from 1GB to 2GB, just to keep things running smoothly. As I write this blog post, Windows 7 Professional is merrily installing itself in the partition where Windows XP Home used to be. After that, I think I may call it quits, but that battery upgrade is tempting…
In my experience thus far with the li’l bit bucket, it’s not too bad a machine. For the applications I run the most — those being my web browser, an IDE, and maybe a document or two — it’s pretty darn snappy, even. The mobility factor is something that I’m still only getting used to, but it’s nice to have a true “laptop.” I no longer have to worry about lugging around my 8+ lb., battery-devouring, desktop-replacement of a notebook, and there’s no need for a lapdesk or cooling pad to protect my body from high temperatures.
I believe the only mentionable issues for me with this new addition to my toy collection are the screen size and resolution. As a developer I value these two things greatly — the more lines of code I can see without scrolling, the better. Even in light of that shortcoming, however, I see the eeePC becoming an oft-used tool in my repertoire, if simply for the fact that I can take it just about anywhere and get a reasonable amount of work done without a lot of hassle.
I know some other guys and gals around who’ve expressed curiosity about using netbooks for development and the like, so if you have any questions, send in your comments and I’ll try to answer as best I can. Until next time!
If you’re into graphical rendering work I highly recommend you check out POV-Ray, the Persistence of Vision Raytracer. Some casual programming is required, but it’s well worth the results you get. POV-Ray is capable of rendering Pixar-like graphics at any resolution using a technique known as raytracing, which “traces” the path of light rays leaving a light source and plots the results on a projected three-dimensional plane. What this computationally-intensive process gets you can be nothing short of amazing.
To whet your palates, I’ll be including some images created by my girlfriend, as well as some international award-winning snapshots. I may entertain requests to put up a beginner’s tutorial on POV-Ray if anyone is interested.







Not too shabby, eh? See what I mean? Now obviously the last two images would take quite a while to accomplish, but the others were all done simply by playing around in the development environment. I would say maybe a few hours’ work went into each one, and they’re beautiful. If this sounds like your cup of tea, head to POVRay.org and check it out!
Normalization is about optimizing large numbers of small CrUD operations, and retrieving small sets of data in order to support those crud operations. Think about people modifying their profiles, recording cash registers operations, recording bank deposits and withdrawals. Denormalization is about optimizing retrieval of large sets of data. Choosing an efficient database design is about understanding which of those operations is more important.
–RevMike, commenting on this post at Jeff Atwell’s Coding Horror blog
Just thought I’d share this little tidbit. I happen to be wrestling with the age-old “normalization vs. de-normalization” argument myself at this very moment, so it’s apt.
Well, I’ve been mucking around in Python v3.1.1 for a few days now, and it’s… interesting, to say the least. I believe it’s starting to grow on me, but then most programming languages tend to grow on me. I even have a place in my heart for Prolog, ferchrissakes! (No offense to Prolog fans, of course.)
It seems like there are a few hangups people have in common when they talk about any aversions to trying Python, so let me give my own perspective based on what I’ve seen and done so far:
- Indentation — By far one of the smallest hurdles. I thought this would be difficult to get over too, but to my great surprise I haven’t slipped up at all, except for a couple times right after I downloaded the language and started playing around. At least in my experience thus far, Python’s rule of enforcing proper indentation is not a big deal. Completely over-hyped. Plus, it actually does make coding simpler: no more brackets to match up, better readability, and it’s much easier to type.
- Speed (or lack thereof) — To put this plainly, there are two things to know when you start talking about Python’s runtime performance. First, comparing a language like Python to a lower-level language like C or even C# is more than a little unfair. Python was and is meant to be a scripting language; that means in exchange for abstracting away all the complications of dealing with OS-level problems like portability and threading, you should expect a small decrease in performance. However, because it’s reaping the benefits of active development and improvement, performance is getting better all the time. Plus, if you compare it with other languages in its class — Ruby, Lua, Perl, bash — you’ll find Python’s not really a slouch in the first place.
- Backwards incompatibility — This only applies because we’re discussing Python 3, as opposed to the also stable and much more popular 2.x branch. Yes, it’s true that Python 3 is incompatible with past versions, but that’s the way the powers that be have willed it — and for good reason. Guido van Rossum and company are working to maintain the practicality of the language they created, and from time to time that means cleaning out the cruft. Python 2.x had a few glaring flaws that needed to be fixed, and so in lieu of making the inner workings of the language that much more complicated, the decision was made to streamline and optimize. Some thought, you’ll find, will also reveal that Python is not the only language to which this same thing has happened — remember that the entire .NET suite of tools undergoes massive renovation every few years. True, basic compatibility persists for the most part among the different versions, but try porting .NET 3.5 code back to .NET 1.1 without giving yourself a migraine — I dare you.
- Data structures — It’s true: if you’re planning on taking up Python, there are a few data structures (possibly new to you) that you’ll need to learn before you get too far. Fortunately, they’re data structures you should already know about if you really consider yourself “into” programming: dictionaries, lists, stacks, sets… really some pretty basic stuff. The big point to consider here is the fact that if you want to code in proper Python style, you should learn to utilize these structures appropriately when they’re needed. But you don’t have to, it’s really your choice. The language doesn’t actually force you to use that stuff, but life is generally easier if you do.
- Dynamic typing — I really wouldn’t consider this a big deal. Scripting languages in general have this issue, so it’s not Python-specific. The only people who should really notice anything are those coming from more traditional, “higher-strung” languages — basically most compiled languages (C, Java, Pascal, etc). It took me a while to get used to dynamic typing when I started learning Ruby, but when take the time to look back, it’s almost relaxing to not be required to declare variable types, much less deal with the hassles of casting between them all the time.
Of course, even with those things out of the way there are a couple aspects of Python that I have struggled with from time to time, so let me get those out while I’m still on-topic:
- Slices and slice notation — Coming from just about any other language besides Python, having a background in programming, could you tell me what the expression
"abc"[1:3] means? For the curious, it returns the string "bc", but how about "abc"[::-1]? That’s basically how you reverse a string, so such an operation would return "cba". I think you can see what I’m getting at here, and it’s that Python has a pretty “unique” way of implementing array slices. I can sort of see the syntax as a metaphor toward arrays, but it’s still more than a little confusing at first blush for newbies like myself.
- Everything’s an object… sort of. — I’m an OOP kind of guy, so I appreciate the heck out of making everything (and I do mean everything) an object. For me it’s just very intuitive. However, I’ve got only one complaint on the matter: why, if everything is an object, can I say “abc”.capitalize() but not “abc”.length()? And why is the preferred syntax for string length written as len(”abc”)? Isn’t that more procedural than object-oriented? Maybe it’s because I’m new, but sometimes I find that object methods aren’t in the places I expect them to be. I’ll probably get over it, but it’s mildly frustrating.
And then there’s one more tip I’d like to share before I wrap up this post… it may be common knowledge to those already versed in the ways of Python, but to anyone who’s interested in learning: list comprehensions are VERY powerful. Maybe too powerful. I’m still trying to wrap my brain around it in my spare time, but I’m pretty sure it should be a duty of any growing Pythonista (including myself) to study the concept closely. It seems such a tool would be quite valuable in the hands of one skilled enough to use it.
If I’ve piqued your interest in Python, or if you feel like you want to learn more, here are some tutorials I’ve gotten good use out of. And as always, please share your own thoughts, opinions, and experiences. I read every one of them, and I appreciate them all.
I know I promised myself that this blog was created as a personal outlet, but I won’t lie — I’m pretty darned excited that traffic is sort of picking up around here. Yesterday we broke a record with (don’t laugh) 5 visitors! Just thought I would help everyone feel appreciated, because I really do appreciate every reader I get.
Look forward to more posts in the near future dealing with my first exploits in Python 3, as well as a couple other topics that have been tumbling around in my brain.
November 3rd, 2009 in
Uncategorized | tags:
meta |
No Comments
In what I remember from my own college experience, this blog entry by Joel Spolsky couldn’t ring any truer in its message.
To sum up a 1000-word post into a sentence or two, Joel is basically saying that students have an incredibly hard time delivering meaningful work in an unmanaged, project-based environment. When trusted to delegate to each other or work together on small teams, the lack of a recognizable authority figure creates a productivity sink. As a result, most comp-sci capstone projects come to fruition as the offspring of a few late-night programming binges, rather than well-defined and well-polished, near-professional quality products. Because I myself went through this “syndrome,” we’ll call it, I can very plainly attest to the truth of these statements.
Spolsky goes further to state that universities often sacrifice putting valuable “real-world” concepts into the curriculum to make room for theoretical. At best, lessons taught in the classroom lean toward the interesting rather than the applicable. Again, pretty agreeable from my standpoint — by the time I graduated, I’d coded and thrown away more short programs than I care to think about. Sure, a lot of that stuff is very useful in learning more advanced data structuers and programming techniques, but maybe a couple more hours spent at the drawing board instead of the textbook would help us budding developers out a bit.
Delving deeper still into his post, I’d like to point out Joel’s mention of Scrum and its potential as a learning and productivity tool in capstone projects. As faithful readers will know, I think I’ve fallen in love with the Scrum philosophy, but I never really thought to apply it when I’d only barely heard about it back in college. It would’ve been unbelievably useful on team projects back then, especially given that I only saw some of my classmates a couple of times per week.
To sum up once again with a quote from the article, “Students have exactly zero experience with long term, team-based schedules. Therefore, they almost always do crappy work when given a term-length project and told to manage their time themselves.” In my opinion, this is completely believable (if not the truth by-and-large); as such, it warrants an examination of the way comp-sci students today are receiving formal instruction. Instead of preparing us to correctly choose the optimal sort for traversing the first n nodes of a dynamically-generated graph, it may benefit us more to learn the processes and the labors involved in actually shipping a software product. Not all necessary work is interesting, but neither is all interesting work necessary. There must be a balance.
Well, that’s it for my rant on the aspects of the typical comp-sci curricula. If you have an opinion and you want to weigh in, please post your comments below. I promise I won’t bite, and if you’ll check the tags on this post, I’m well aware that this has probably been a rather inflammatory collection of thoughts.
October 29th, 2009 in
Uncategorized | tags:
college,
education,
inflammatory,
learning,
links,
long-post,
project-management,
rant,
scrum,
software-development |
No Comments
Python, that is. I just installed v3.1.1 (the current stable version of the 3.x series) on my laptop, so you can expect me to be tinkering with it off and on. Keep an eye on this space for anything interesting I happen to find along my journey.
EDIT 2009-11-04: Re-wrote the last sentence or two. It just felt a little wordy.
I was running around the web not too long ago, and I happened to stumble upon Jason Cohen’s blog. It’s aptly named “A Smart Bear,” as it chronicles his perspective as the founder of Smart Bear Software. I’m pretty curious lately about all this microISV business — partly thanks to my buddy Noble Bell, who’s the owner and sole proprietor of a microISV himself — so I looked a little further, and eventually I found myself reading this article, entitled Too Small To Fail: How Startups Can Grow in Recessions.
Cohen’s blog post basically sums up the story of Patrick McKenzie, creator of a very unique but very niche-marketed software product that has become very profitable in the last few months. It’s called Bingo Card Creator, simply enough, and that’s exactly what it does. McKenzie’s software generates randomized bingo cards automatically with the push of a button; the cards can feature the traditional 1-70 Bingo numbers or any of a range of symbols, pictures, words… basically right up to the limit of paper-printable user input. And people pay for that functionality, whether it’s Granny at the bingo hall on Thursday nights or Ms. Jibberjabber making educational games for her class of third-grade munchkins.
It’s hard to believe that such a specific product is so profitable, and I have to say I give my applause to Patrick for all that he’s done. He gives hope to all the rest of us “little guys” who would like to eventually hang our own sign on that big storefront we call the Internet. Cohen says — and this makes a great deal of sense if you think about it — the distinct advantage in dealing with niche markets is the relative lack of competition; compare this to more mainstream apps like office suites or image editors, where mega-corporations have nothing less than a stranglehold on the market. Sure, you may not have as many users to which you can sell your wares, but they’ll be all the more faithful and likely to buy from you in the future… plus, they’re probably more likely to tell their friends, I would wager.
These two — Cohen and McKenzie — enlightened me once again to the fact that sometimes we get too caught up in illusions of grandeur, trying to “take over the world” so to speak. If one guy can make $3,600 in a month generating bingo cards, maybe that’s a sign to the rest of us. Thinking big but starting small might not be such a bad idea.