The path to opening a Geek Ranch is not exactly straight. That is, each week there is one more strange thing that needs to be done. This week, it happens to be surveys. Not the measure the ground kind—we already did that—but the on-line ask questions kind.
While our primary focus is renting geek cabanas, there has been some interest in buying space in the facility or at least acquiring space on 99 year leases. One opinion lead to another and it became clear that for us as well as people in the Nicaragua real estate market in general, a survey would be in order. So, time to write one.
I started writing a multi-group survey using PHPSurveyor a few days ago. Being an ex-software tester I managed to break it. The good news was that I found that there was a new version and that new version even included a new name, LimeSurvey. It's pretty and clean and multi-lingual and lots of other good things. Besides that, it didn't blow up with the survey I was working on.
There is little reason to offer a blow-by-blow of setting up a survey. LimeSurvey is designed for the GUI crowd. It is full-featured and once you get used to the icons and the hierarchical structure (survey->group->question) and label sets you should be home free.
I was originally running PHPSurveyor on a shared host where I have shell access. Where I really wanted it was on a different shared host where I only had FTP access. I decided it was worth a try. So, I unpacked the tarball locally and FTP-ed file hierarchy over. The additional setup I needed before I could just start talking through the web server was minimal:
- Manually create a database.
- Edit config.php to set up database access information and a few other minor things.
I then went to the admin page and all seemed well. That is, until I tried to upload my old survey that I had saved from PHPSurveyor. It failed but the error message suggested a permissions problem on a temporary directory. The suggestion was correct, I fixed it and all was well. All in all, not a bad experience.
In theory, I could stop talking now and you could just go use LimeSurvey. If you have written serious surveys before—whether it was on paper, writing your own software or using a different package—that would probably be true. But, by far, the hardest part of the whole process is designing a survey that makes sense. LimeSurvey will help you out but here are some pointers.
One thing I learned long ago is that if you have a big task, breaking it up into smaller tasks is always of benefit. In the case of a survey, you will probably have questions that logically belong together. LimeSurvey offers groups which are sets of questions that you can then include in the full survey. For example, if someone is a Linux user, you might want to ask them how long they have been using Linux, which GUI they use and what Linux "brands" they use. These questions could be put into a group, worked with as a logical unit and finally included in a survey. LimeSurvey even allows you to present questions a group at a time to someone taking a survey rather than only a question at a time.
Along the same line of thinking, if you asked someone if they used Linux and they said no, there would be no reason to ask them the group of questions I just discussed. LimeSurvey to the rescue once again. Its branching feature allows you to selectively ask questions based on the answer to a previous question or questions.
The interface to do this requires a minimum of thinking. That is, there are no regular expressions to deal with and such. You add conditions by picking (clicking on) a previous question and then selecting the answers (again by clicking) that you wish to use. This is also not limited to a single question—a question can have multiple dependencies.
While there is no "build some conditions and use them over" capability you get close. Once you set conditions for one question, you can copy those conditions to other questions. The only caveat is to make sure you don't have a condition that depends on a question that might have been skipped do to other conditional logic.
Another very useful feature is label sets. This gives you the ability to define a set of labels for use in multiple places. For example, if you wanted a "scale" as answers to a set of questions where there were three answers, you could use a label set. The label set would relate codes to the textual answers. You then just reference the label set. For example, if the answers you wanted were Gnome, KDE and shell, you could just put those choices in a label set (say interface) and then reference it when writing your questions.
At the question level, you have lots of choices. In fact, 25 which the documentation divides into:
- Single choice questions
- Multiple Choices question
- Other types
The easiest to understand are single choice questions. There are five choices here: three different text sizes, numerical input and date. These formats can be further restricted by what are called Question Attributes. For example, you could define the maximum character length for a text field.
Multiple choice questions are just what you would expect. You can, however, control whether they will be displayed as a drop-down or radio buttons. You can also turn on an "other" answer. Multiple answers (check boxes) are also available.
Lists and arrays allow you to present sets of questions. There are enough options here that I will just say if you can think of something you want to do, it is probably available.
In the other category are the ability to ask the user to rank the items displayed, a boilerplate display (not really a question) and the ability to select a language.
Some other features worth mentioning are:
- Assessments—The ability to selectively display text based on evaluation of some answers. This gives you the ability to offer immediate feedback after completion of a survey.
- Multiple users—Multiple people can build and run surveys based on one running copy of LimeSurvey.
- Templates—Multiple looks are included but if you want to go beyond that, you can edit the templates and styles for survives.
- Multiple languages—LimeSurvey uses GNU gettext message catalogs and is already translated into many languages.
- Selective access—An invitation which includes an access token can be sent to people and they access can be tracked.
This should be enough for you to decide if LimeSurvey is something you might need and, if so, give it a try. Now, you are invited to take my survey here. Have fun.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- Google's SwiftShader Released
- SUSE LLC's SUSE Manager
- Interview with Patrick Volkerding
- My +1 Sword of Productivity
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Managing Linux Using Puppet
- Non-Linux FOSS: Caffeine!
- Tech Tip: Really Simple HTTP Server with Python
- SuperTuxKart 0.9.2 Released
- Parsing an RSS News Feed with a Bash Script
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide