martinpace.com

Latest Entries »

United Nations Internship

Filed Under: Career by Martin — Leave a comment

Dec 21, 2010

I recently received an internship offer with the United Nations secretariat in New York City. With over 7,000 applicants and approximately 200 accepted, this is a very prestigious feat and an incredible opportunity – I honestly can't fully express what this opportunity means to me. It opens so many doors for a future of living abroad due to the people I'll meet and the experience I'll gain. I've never been to New York City, so needless to say I am very excited!

As the UN covers no expenses whatsoever and the internship is unpaid and full-time for 2 months, I was at first fretting over how I would be able to afford any of it. Sure enough, I received overwhelming support and encouragement from my amazing co-workers and friends, many of which have been helping me sort the finances and university matters. This is not the kind of opportunity one turns down and my friends made sure I knew that. Indeed, I've already scanned a signed copy of the offer letter and the internship agreement to the UN's internship office. I'm now finalizing all of my arrangements for the trip.

I'm not sure yet what I will be tasked with, but I should find out upon my arrival in January. For those of you other applicants who are still waiting to hear back, let me outline the timeframe of my application process and offer:

August 26 – Registered an account at careers.un.org.
September 10 – Successfully completed and submitted the internship application.
November 15 – Received an inquiry as to my interest and availability, as well as notification that my application met preliminary requirements, which I interpreted as "you're in the pool of applicants from which we will select interns."
December 13 – Received the internship offer (letter and internship agreement). The internship starts January 17 and ends March 11.

I still have a hard time believing that I was selected out of so many applicants from all over the world. I read my offer letter about 3 times on the laptop screen, then printed it out and read it another 5 times, and then read it 3 more times from my smartphone. I'm honored to have this opportunity.

The past 2 weeks have shown me that I have a lot of true friends, great co-workers, and encouraging professors cheering me on and they know who they are. It's going to be great. Wish me luck!

Tags: internship, United Nations

Comment

QMYSQL Driver: Not so Qt at first glance.

Filed Under: Programming by Martin — 2 Comments

Jun 7, 2010

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!

Tags: .NET, database, Java, MySQL, ODBC, Oracle, QMYSQL, Qt, QtCentre, software, SQLite, Visual Studio, Windows

Comment

Wiki Markup vs HTML Markup

Filed Under: MediaWiki, Wiki by Martin — Leave a comment

Feb 17, 2010

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.

Tags: html, markup, MediaWiki, wiki

Comment

There shall be no wikiwaring on the wiki!

Filed Under: Wiki by Martin — Leave a comment

Jan 6, 2010

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.

Tags: content, wiki, WikiMedia, wikiwar

Comment

Always try to categorize when appropriate.

Filed Under: MediaWiki, Wiki by Martin — Leave a comment

Dec 29, 2009

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.

Tags: design, longevity, markup, MediaWiki, wiki

Comment

A few simple templates can make life easier.

Filed Under: MediaWiki, Wiki by Martin — Leave a comment

Dec 25, 2009

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.

Tags: content, html, markup, MediaWiki, template, wiki

Comment

Designing your wiki is the first step!

Filed Under: Wiki by Martin — Leave a comment

Dec 22, 2009

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!

Tags: design, longevity, wiki

Comment

Is a wiki right for you?

Filed Under: Wiki by Martin — Leave a comment

Dec 21, 2009

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.

Tags: collaborative, community, design, MediaWiki, project, wiki, Wikipedia

Comment

martinpace.com

Latest Entries »

United Nations Internship

QMYSQL Driver: Not so Qt at first glance.

Wiki Markup vs HTML Markup

There shall be no wikiwaring on the wiki!

Always try to categorize when appropriate.

A few simple templates can make life easier.

Designing your wiki is the first step!

Is a wiki right for you?

Recent entries

Browse popular tags

Meta

Friends & links

Pages

Monthly archives