Latest Entries »

QMYSQL Driver: Not so Qt at first glance.

Please note that I was using Qt 4.6.2 with MSVC 2008 as my compiler and MySQL Server 5.1 on Windows 7 32-bit at the time of this post.

For a while now, I've been interested to see how friendly Qt is with developing applications that interact with MySQL databases. When I set out to toy around with Qt's QtSql module, I learned some important things about how database interoperability in Qt depends heavily on drivers for the various database management systems (MySQL, Oracle, ODBC, SQLite, et. al.). This is to be expected, as with .NET and Java. However, the bump in the road I was encountering was that the QMYSQL driver (each DBMS has a corresponding driver, such as QODBC, QSQLITE, and in my case, QMYSQL) is not included by default, depending on if you compile Qt yourself (how you do so and in what environment are both important factors).

Although helpful, the Qt documentation for the SQL drivers was sparse at best, and did not mention some nuances associated with the process.

First, I wrote some basic code to test connectivity, and I could not open a connection with my MySQL database by any driver except QSQLITE, which could connect, but could not select any tables in the database. Before trying QSQLITE, I had given QMYSQL a try, but Qt appropriately informed me that the driver (a plugin) was not loaded.

With this information, I embarked on a journey to find out what I needed to do in order to load the driver. My initial investigations suggested that I needed to obtain the driver first, before it could be installed or loaded. I found it mind-numbingly difficult to obtain this information, because I had to dig through tons of Qt mailing list archives and old forum threads on QtForum.org (now defunct) and QtCentre.org (active) before I could find even this bit.

Next, I needed to know what I needed in order to build the QMYSQL driver plugin for Qt and then make use of it. It turns out, I needed to download the installation for MySQL Server, run it, choose Custom, and then install the C Include Files / Lib Files. That was easy.

Following that, the next step was to compile the QMYSQL driver, which requires the contents of $QTDIR%\src\plugins\sqldrivers\mysql as well as the contents of C:\MySQL\include and the C:\MySQL\lib\opt\libmysql.lib file.

Indeed, the aforementioned Qt documentation for the SQL drivers provides instructions for compiling each driver on both Linux and Windows. According to the documentation, it's as simple as doing the following in the Qt command prompt once you've installed the necessary files:

cd $QTDIR%\src\plugins\sqldrivers\mysql
qmake "INCLUDEPATH+=C:\MySQL\include" "LIBS+=C:\MySQL\MySQL Server <version>\lib\opt\libmysql.lib" mysql.pro
nmake

However, if you're on Windows and especially if you're using MSVC as your compiler (meaning you're using "nmake" instead of "make" in the Qt command prompt), then there is a major caveat that will ruin your day if you don't know about it (and most people don't, unfortunately). Basically, nmake is not at all friendly with file paths that contain spaces. This means that you will likely need to reinstall MySQL to a path on Windows that does not contain any spaces in any of the directories that are part of the path. This was incredibly frustrating, because there's not really a way to substitute a special character when these filepath strings are passed to nmake from the Qt command prompt or the mysql.pro file. I tried the various "space" equivalents and had no success. Luckily, uninstalling and reinstalling MySQL to a new location (i chose C:\MySQL\ instead of C:\Program Files\MySQL\MySQL Server 5.1\ which is default) was quick and easy.

Now that I could specify a path that contained no spaces, things were perfectly fine. The QMYSQL plugin compiled quickly and successfully. Alas, victory! Or so I thought…

The next issue I had was that my QSqlDatabase object kept saying that the QMYSQL driver was not loaded. This was a rather annoying issue that I spent yet another hour and half finding a solution for. Luckily, a respondent to an older thread on QtCentre.org suggested that the libmySQL.dll from C:\MySQL\bin\ needed to be copied and pasted into the directory where the binaries for the application were residing (either \debug\ or \release\, respectively).

After doing that, my little test application succeeded in connecting, running a query, and returned a nice little result to me without any issue whatsoever. Now that this hiccup has been overcome, I see that MySQL development with Qt will be both surprisingly simple and extremely elegant. It would be nice if the Qt documentation were updated to mention some of these caveats. In the meantime, I hope people will find this post of help!

Career Path Research & Decision Making

You may as well go ahead and face it. To get what you want out of life you will have to work for it. Such is the way of the world. We have many choices to make about the kind of life we want, but never a road map to get there. It certainly helps to get anywhere if you'll at least know where you are when you get there. Perhaps you are slated to graduate from secondary school with many questions about what awaits you in the working world, or perhaps you are an adult with children who graduated from high school years ago and are unsatisfied with your line of work. Identifying and then pursuing a career is and forever will be a daunting endeavor if you haven't given it any thought or are otherwise unprepared. It doesn't have to be that way. You can find out what you want to do, where you want to go, what it will be like, and how to get started.

Very few people just fall into a career (and at that, even fewer fall into one they end up loving). Identifying a career takes some work – some research. Deciding on a career requires some initiative. Pursuing that career requires some dedication.

I graduated from high school in 2005, and during my senior year, I had to complete an array of assignments having to do with fields of study, career paths, etc. These research papers and essays ended up being some of the most important I've ever written. Many students enter community colleges or universities without having a clue what they want to do, let alone what they wish to study. Often, these students will change majors, take classes that go off in tangents, and end up wasting a lot of time and effort. Some students go so far as to graduate with a degree, and after they've graduated, the only thing they've learned is what they don't want to do. What a waste of time. (Not to mention, money!) I on the other hand, knew exactly what I was interested in doing even since my senior year in high school, and I have not deviated from it since. I've never taken a class I didn't need, I've never dropped a class, and I've never changed majors or shifted my objectives. I've been able to stay on track because I had already done the "figuring out" part before jumping into higher education and starting towards my career. What's more is that I am ultimately extremely happy with the choices I made and the career I am pursuing. I couldn't ask for more from my experiences than that.

I wasn't one of those students who had to struggle with finding my passion and identifying my career path – and you don't have to be either. If you already are, then stop what you're doing, follow my advice, and get this research out of the way so you don't waste another minute or another dime.

You're going to have to do some solid research if you want to figure out what line of work you would like to enter, and what you'll need to do in order to succeed in it.

The following is a list of immediate questions you should answer as you begin researching potential career paths and making career decisions:

  1. What are your most prominent interests? Consider how you spend most of your time versus how you would like to spend most of your time. A career that you love and enjoy will capitalize on the things you love doing and curtail the things you hate doing.
  2. When do you want to work? Are you a morning person, afternoon person, or night person? What hours do you wish to work, and how many of them per week?
  3. Do you want to be your own boss? Do you enjoy working for others? Do you enjoy working as a team with others?
  4. What are the working conditions of the career path you're considering?
  5. How much do you want to earn in a year and what kinds of salaries are prevalent in the career path you're thinking about?
  6. What are the growth prospects for the field you're thinking of – how healthy is the employment for that industry or line of work?
  7. Are you creative? Do you want a line of work in which you can express your creativity?
  8. Might you enjoy helping others? Perhaps a health career is right up your alley – health jobs are often consistently in high demand and can be quite lucrative.
  9. What are the levels of education and certification that commonly coincide with the line of work you're looking into?

The following are some extremely helpful resources for finding information as you do your research on career paths:

  • CareerPath.com – Free Career Tests
    Take some of the free career tests at CareerPath.com to try and figure out what you might be interested in and what you might be good at. Please note that the results you receive from such quizzes are not definitive – rather, they're just suggestions. You might be really good at something even though it didn't show on an aptitude or preference quiz. However, if you are truly in the dark about what interests you and how you can match up your interests with real-world work, these types of quizzes can be very valuable to you. CareerPath.com has some nice ones, but it isn't the only one. Feel free to Google for others, maybe even take a personality assessment quiz and see what types of careers might be in alignment with your personality.
  • Bureau of Labor Statistics – Occupational Outlook Handbook
    The Occupational Outlook Handbook (OOH) is one of the most valuable resources for information on nature of the work, working conditions, earnings, education and training qualifications, opportunities for advancement, employment figures, job outlook, and other such information about a given career type, such as a Financial Analyst or Engineer.
  • Salary.com - Salary Wizard
    All kinds of information on salaries (based on job title and geographical location) is available at Salary.com for free. Take a look at the average earnings for various careers in your area or elsewhere.
  • LinkedIn.com – Professional Networking Site
    LinkedIn is a very cool site, perhaps one of the best professional social networking sites around. It consists of various profiles that focus on what people do, where they work, where they've gone to school – you know, professional info. There is also a very valuable Question and Answer feature on the site (akin to Yahoo! Answers, but without all the silliness). Engage in Q&A discussions – you never know when you might learn something new and interesting from an executive or other professional who participates in the same Q&A discussions as you. You might even find a surprising response of gratitude from some of them if you teach them something they didn't know. I've met some really awesome people on LinkedIn, some of which I've helped with projects or consulted with on questions they had about things that I know well. LinkedIn is a great resource – use it – even if you're not out of high school, and even if you're not in the professional working world yet.

Furthermore, when in doubt – just ask someone else! Meet your parents' friends and co-workers, talk to them or ask them questions about what they do and what all is involved, and see who they know in various fields – they will likely be interested in helping to connect you with someone who is capable of offering you some advice. Networking is key – it is now, it will be during higher education, and it will continue to be once you've entered the professional world.

Wiki Markup vs HTML Markup

Most wiki software offers two choices of markup when formatting content. Typically, most of them allow HTML markup, but more importantly they offer a special markup such as that of MediaWiki, or some equivalent to BBCode which is the de facto standard used across the most common forum softwares.

In nearly every case (with a major exception being templates), you should opt to use wiki markup rather than HTML markup. One of the key principles behind massive-collaboration engines such as MediaWiki, is that content should be easy to edit and format by anyone, including (quite especially) those untrained in HTML markup. I have heard some argue in favor of embedded WYSIWYGs for wikis – I am perhaps a bit more old-fashioned, but I have not yet formed a solid opinion one way or the other on this. I may address it in a future post.

In short, this means you should opt for using wiki markup to create tables, lists, and formatted text rather than HTML in most cases. As well, you should opt for the following (assuming MediaWiki):

'''Strong'''
''Emphasis''

*Unordered List Item 1
*Unordered List Item 2

#Ordered List Item 1
#Ordered List Item 2

[[Internal Link|Internal Link Text]]
[External Link External Link Text]

Rather than:

<strong>Strong</strong>
<em>Emphasis</em>

<ul>
<li>Unordered List Item 1</li>
<li>Unordered List Item 2</li>
</ul>

<ol>
<li>Ordered List Item 1</li>
<li>Ordered List Item 2</li>
</ol>

<a href="">Internal Link Text</a>
<a href="">External Link Text</a>

MediaWiki provides a complete Help document for Formatting.

There shall be no wikiwaring on the wiki!

Like everything else in life, war has found a way to inject itself into the world of wikis. WikiMedia defines wikiwar as a scenario in which two or more parties disconnect from one another in disagreement over how content should be organized, what content should exist, and how a website (in our case, a wiki – or some other collaborative environment) should be managed, whereby these parties engage in tug-of-war tactics and waste large amounts of time and exert incredible energy into thwarting their rivals by undoing each other's changes or making it more difficult for each other to make changes. Once a wikiwar degenerates beyond its fatal threshold, one party will back down and submit, or else they will be blocked and banned.

Wikiwars are bad ideas all round. They are unproductive and destructive. They just aren't worth it. If there's a discrepancy on the wiki, ask other contributors about it or run it by whoever is in charge of oversight. Choose the diplomatic approach. It's just not worth the time, energy, emotion, or loss of progress to engage in a wikiwar.

There should also never be any turf wars on a wiki. Never let yourself become too intimidated to edit pages or reorganize content. If a mistake is made, it can be corrected. Nobody should get defensive over an area of the wiki, and nobody should succumb to the misguided assumption that they have "territory" on a wiki. If you don't know what you're talking about, you certainly aren't going to be editing a page for content that you don't understand – so that isn't a concern. If you aren't supposed to be editing a page or reorganizing certain pages, then those pages will be locked/protected by administrators – so what is there to worry about? Just try to be cautious and use your best judgment. When in doubt, ask another contributor (perhaps the last contributor to edit the page you're considering revising) or an administrator.

Always try to categorize when appropriate.

When dealing with a wiki, longevity is key! I've made that point already, but I'll continue reiterating it so that it is sure to sink in. Each page you create in the short term is another step down the long term road. As your wiki grows, you need to make sure that it doesn't fall short in: content quality, content accuracy, and content organization. One might even call those the three Cs of a wiki – perhaps I will at a later date.

So clearly, one of our primary objectives is to keep a wiki maintainable, so that we can provide it with longevity. One of the simplest ways of keeping a wiki maintainable is making everything organized and easy to find. Nothing can truly be "lost" (as in, become unable to be found), because you can always find uncategorized pages. However, when a wiki user is caught up in the moment, it can be quite easy to get lost or find difficulty in locating certain pages or content.

When designing your wiki, you were advised to think about the following question:

  • What categories will be derived from the wiki's overall subject matter?

In short, this means that you would've identified the overall topic of the wiki, and then would've derived from it, certain categories to be used for organizing sections (no matter how large or small) and pages of the wiki.

Different wiki software has different markup, but in MediaWiki you can very easily categorize a page by appending the following to it:

[[Category: Name of the Category]]

I recommend prepending this to the top, or appending it to the bottom of the article's wiki code. Depending on your theme, the category will be shown at the top or bottom of the page once saved, but that will happen regardless of where the categories are positioned in the wiki markup, so it's more sensible to put them at the top or bottom so that they're out of the way of everything else and not scattered about randomly.

The result on the page would look something like this:

Category: Name of the Category

You can add as many categories as you would like, as follows:

[[Category: Mercedes-Benz]]
[[Category: M-Class]]
[[Category: M 2010]]

The result will be:

Category: Mercedes-Benz M-Class M 2010

Categorization is perhaps one of the most important initial steps towards properly organizing pages on your wiki, and it's so simple that there's never a reason not to do it. Keep in mind that those categories will show up red until they are clicked on and a page is created to explain a given category. However, they will function properly even if you never create the category pages for them.

A few simple templates can make life easier.

With templates being so easy to create and implement on a MediaWiki installation, there's really no valid reason not to use them. If you're unfamiliar with MediaWiki templates, please note that a template in this case is not synonymous with a style, skin, or theme. MediaWiki supports those as well, but templates are of special interest because they can make life on a wiki so much easier.

First of all, a template allows you to create wiki markup, as you would when creating or editing any other page on the wiki. Additionally, templates support as many variables as you so choose to give them. This means that you can create the markup for the presentation of some content in a template, and then insert variables where you desire dynamic information to be displayed. Once you have the template created, you can use it on as many pages as you wish and you can always go back and edit it as needed. You can do all of this on the wiki directly – you needn't edit any files of the MediaWiki installation.

Templates are especially great for times when you need a lot of articles (or perhaps sections of articles) to contain important information that you would like to be formatted neatly and consistently. For instance, let's assume we are documenting a bunch of different makes and models of automobiles, each vehicle having its own page on the wiki.

Ordinarily, we might create pages that contain the following table:

Wiki Tables

{|
| '''Make''' || Jeep
|-
| '''Model''' || Grand Cherokee
|-
| '''Year''' || 2000
|-
|}

HTML Tables (Not Recommended)

<table>
    <tr>
        <td><strong>Make</strong></td>
        <td>Jeep</td>
    </tr>
    <tr>
        <td><strong>Model</strong></td>
        <td>Grand Cherokee</td>
    </tr>
    <tr>
        <td><strong>Year</strong></td>
        <td>2000</td>
    </tr>
</table>

If we choose one of the above methods, either Wiki Tables or HTML Tables, it's rather simple and Wiki Tables are a bit more clean in the wiki source for an article (outright HTML unless absolutely necessary is not advised, for sake of keeping the wiki friendly for people not versed in HTML markup).

We will end up with something like this:

Make Jeep
Model Grand Cherokee
Year 2000

However, we may not want to type out all of the text for the Wiki Table or the HTML Table each time we create a page for another vehicle. We may not even wish to copy and paste the table and scroll through and change values. Wouldn't it be nice if we could design the table & format of the content only once, and then from there on, just assign values to the variables Make, Model, and Year? Fortunately, with wiki templates, we can accomplish exactly that!

We're going to create a template called Vehicle, and use it to format information for the Make, Model, and Year of any given vehicle. Then we're going to use it on a page. On MediaWiki, enter Template:Vehicle into the search box and click Go. You will be taken to a page that will say something like "There is no page titled 'Template:Vehicle'. You can create this page.", so go ahead and click on create this page.

Now, enter the following Wiki Table markup onto the template page:

{|
| '''Make''' || {{{1}}}
|-
| '''Model''' || {{{2}}}
|-
| '''Year''' || {{{3}}}
|-
|}

You can insert as many variables as you want by enclosing an integer in triple braces: {{{x}}} (x is an integer). The variables will be set in an ascending order starting from 1.

Now we have a reusable template, so let's see just how easy it is to use. Assuming we're going to create an article for a Grand Cherokee, we'll include this template and fill in the proper data by entering the following onto the Grand Cherokee article:

{{vehicle|Jeep|Grand Cherokee|2000}}

This will show up on the page just the same as if we had included all of the table markup. However, including all that markup is redundant and unnecessary in light of templates. The following is our result:

Make Jeep
Model Grand Cherokee
Year 2000

This is a very simplified example, but it still helps make repetitive content easier to add while maintaining cleanliness. Your templates can be much more complex, and your data and desired formatting may demand that they be. In the future, I will be sure to offer more advanced examples of how templates can be useful in complex situations. I hope this encourages you to make use of templates on your wiki. It will help you maintain your sanity in the long term.

Designing your wiki is the first step!

The first thing you need to do in your endeavor to implement a wiki is to design it. This is perhaps the single most important step in the early stages of your wiki's development. Whether you perform this step before/after installing a wiki software is up to you, but you should design before you start creating pages and populating your wiki with content. When I say "design," I am referring to the structure and organization of the wiki, not the cosmetic appeal.

Here are some topics to think about and questions you should ask yourself:

  • What is the purpose of the wiki?
  • How many contributors are expected to be collaborating on the wiki?
  • How often do you expect contributions to be made?
  • How much time (on average) do you expect each contributor will spend browsing and editing?
  • What categories will be derived from the wiki's overall subject matter?
  • What naming conventions will be most appropriate for articles and categories?
  • Will any articles of a certain category contain repetitive information with only details varying?
  • What will be the easiest-to-read format for the content of articles of a specific category?
  • What will be the easiest-to-edit format for the wiki code?
  • How long could the wiki be expected to be used?
  • How large could the wiki be expected to grow over the time it is expected to be used?

It should be duly noted that longevity is key when designing a wiki. If you aren't thinking about longevity when designing your wiki, you're going to stumble later on and realize that your wiki's longevity may be very short.

A wiki doesn't do things for you. Rather, it provides you with a clean, fast, and presentable means of storing information and documentation. That being said, you want to develop the wiki in such a manner that it will be easy to maintain down the road. For instance, you don't want to end up having to reorganize or rewrite loads of entire articles five months down the road. That would certainly be time wasted.

So be sure to plan ahead! Think long term – do your best to forecast the future of the wiki, even if you may doubt its fruition. Design and develop in manners that provide your wiki with longevity!

Is a wiki right for you?

A wiki is a database-driven web application that provides a project, community, or other organization with a collaborative environment in which many contributors can author, edit, and organize content.

The most prominent example of a wiki would be Wikipedia.org, which is a project sponsored by the Wikimedia Foundation, a non-profit organization responsible for the managing of various wiki projects and developing the MediaWiki software that powers them. Wikipedia is an OpenWeb Encyclopedia that you probably already use at least once a week if not once a day – and if you've never visited Wikipedia in your lifetime, I'd be so surprised that I wouldn't know where to begin. Wikipedia is quite a solid and perhaps overwhelming demonstration of a collaborative environment. However, Wikipedia primarily showcases the function of wikis as encyclopedic works. In practice, wikis can serve a variety of purposes. You can document designs, product/project information, policies, and much more.

In particular, I've used wikis for documenting information for open source software projects, game designing, and existing game documentation. That's hardly scratching the surface, however. Wikis can be useful to commercial and noncommercial organizations alike, and can be internal or external. I've consulted with a few LinkedIn connections of mine on designing, developing, adopting, and implementing internal wikis for government organizations, such as the US Census Bureau.

If you're in search of a medium with which you can quickly and easily produce and store content while maintaining a well-formatted presentation of such content, then a wiki may very well be right for you. You should note however, that if you wish to embark on the journey of getting a wiki adopted and implemented then you must prepare yourself to properly design and maintain a wiki over the course of its short term and long term development. It is my hope that the advice I offer on this blog will assist you in this endeavor.

Powered by WordPress. Theme: Motion by 85ideas.