I can't seem to find this on Beatport or iTunes to buy :(
Sometimes, I feel like people give Java a bad rap. It's a language that's in demand out on the field and after using it for my school classes, I have found that it is easy to program in, it performs very well and your code is portable/cross-platform. Sounds great, right? At first glance Java magically turns everything that's hard to do into something easy.
But then I'll use Java-based software and somehow it manages to consistently be extremely complex to setup/configure (ie, tomcat+webapps), to have horrible looking UIs (ie, LimeWire, FreeNode, OpenOffice) and often it consumes lots of resources needlessly (ie, OpenOffice, LimeWire). I mean seriously, you can get a PHP or Python-enabled webserver up and running in under 2 commands on RHEL and then you just need to create a single script file to start serving pages. The Java community really needs to spend some time working on developer/user experience in my opinion.
I've always cared a lot about user experience because I find that no matter how great a single piece or a collection of software is, it is the user experience that shapes your impression of that software. That said, I was cleaning up my (very, very messy) desktop and came across an old backup of a Fedora installation. There was a file on my desktop from July 2008 that I had completely forgotten about... I had collected my thoughts at the time on how Linux-based distributions could be improved to make the user experience better. It's really neat to see how many of these have been implemented in only 3 short years:
my apologies for the messy read, I tend to write my notes in Wiki format and I don't feel like copy/pasteing
<li>'s all over the place ;)
* The Linux installation+boot process
* Installers must try to recognize an existing Linux installation's boot
configuration and add theirs to it, not overwrite the previous one.
* Be able to partition (read: resize) other filesystems intelligently and
* Provide installation profiles. Stop fighting over what packages or
configurations to use and realize that a server, an enterprise and the
typical user all have different sets of expectations and needs.
* GRUB should have an extendable plug-in system where distributions could
plug-in modules to have it suggest which partitions to boot from (ie
* Graphical bootup: X in initramfs. Ubuntu does this already, it's an excellent
idea and gives the user a better overall experience.
* Standardizing the Desktop
* User accounts
* Unix names are confusing to users. Have the system map metanames to Unix
names so that people can login with e.g. "firewing" or "Stewart Adam"
* Allow the administrator to create user groups and define their privileges.
User accounts belong to one or more groups which defines what they can do.
* User control is easy and at the same time they can be given needed
privileges (software updates, mounting drives, etc) without having to
know the root password.
* Unified package management. Create a standard for both package managers and
packaging. This enables large, cross-distro compatible repositories that
benefit the users.
* User experience
* Prompt the user for backups once a week. Include a don't show me again
* Why can't we configure tapping on a per-user basis again? Right, xorg.conf.
* Need to accept and handle user feedback. Although Linux is used by a lot of
developers, most of the users are non-developers users. It would make
sense to prioritize what they have to say.
* If a device is present but isn't supported, provide a signal so that the
desktop environment can present a dialog explaining the problem and showing
the user what they can do to help.
* More specifically, reporting the device IDs and collecting common log
* Create "FooKits" for helping monitor and solve common problems. Power usage,
kernel oopses, SELinux, etc.
* Reload parts of the kernel without rebooting (just improve kmem)
* Don't leave users out in the cold. They shouldn't have to do a day of
research to get the OS installed or to perform simple tasks. Provide
tooltips and help buttons inside programs.
* Dumbing down doesn't solve much. The best type of documentation is easy
to understand but contains technical information at the same time.
* Interfaces need to be somewhat standardized and resemble each other in
nature. They overall goal is that programs should be intuitive -
Documentation should accompany a program, but the interface should be
intuitive enough that users shouldn't have to read it to get started.
* Something nice for the help menu layout:
- Check for Updates (this would use the standardized package manager)
- Report a bug
- Help translate this program
- About this program
* Synchronize user information (ie, UID/GIDs) between various distributions.
* There needs to be an easy communication channel between developers/
packagers and users so that they are encouraged to help out. Testing and
providing feedback and bug reporting and bug sorting/solving is not hard but
goes a long way in helping the developers troubleshoot problems.
After much research, experimentation, testing and tweaking I'm happy to announce that I have completed the first part of my CentOS 5 server setup howto series!
As of today, you'll notice a new CentOS 5 Howtos link on the where I have listed the first two parts of the howto series, the getting started howto which will help you setup a basic system environment and more importantly, the mail server howto which documents how to setup a secure mail server offering POP3/IMAP/SMTP with virtual users stored in a MySQL database.
I'm very happy with this setup because it uses virtual users that cam be mapped to system users and also keeps the software set relatively small; Dovecot is used for SASL authentication (both for POP3/IMAP and SMTP) and for postfix's local delivery agent, so with only 2 servers we've got it all covered (of course technically it's 3 servers with an extra transport if you take amavisd and response-lmtpd into account).
The virtual user database is currently only used in this tutorial for the mail server, but I have plans to introduce (with an upgrade path) a new database structure that will unify several authentication data pools and make managing clients for a shared hosting server easier... But I'll talk more about that later once I've finished posting my other guides. I plan on adding ones for other services such as DNS & Web, although I cannot promise when those will be finished. The mail server tutorial alone is 16 printed pages (!) so it does take me quite some time to ensure that the tutorial is well documented and that the configurations listed work properly.
I still have to add some notes here and there about the implementation, but the core material is there. Enjoy!
I have been working with a client to setup an Ubercart store customized to their needs and one of the things we came across as we launched the store is that because of the nature of the items being sold, it was very difficult to give a accurate shipping estimate. Thus, I set off to find a way to enable customer payments after checkout and to enter the shipping quotes manually.
These two modules, uc_manual_shipping and uc_payafter, are the fruit of these efforts. I hope you find them useful!
Note that this is my first release of these modules and the code should be considered a beta and work in progress. They are untested so far and not recommended for use on a production site just yet. All information about installation, configuration and further development is available in the README.txt file, DEVELOPERS.txt file and/or source code comments. If you have made some changes or improvements, please let me know in the comments! I would love to hear about your changes and I would be more than happy to apply any patches or bugfixes.
uc_manual_shipping enables the store administrators to manually enter shipping quotes on orders after a user has passed through checkout. It can be used in combination with uc_payafter to have users create go through regular checkout without paying, and then pay later once a shipping quote has been submitted by a store administrator.
uc_payafter duplicates the checkout process and allows users to perform payments on their orders after checkout at the URL cart/checkout/pay/$ORDER_ID. Store administrators can email users different invoice templates after payment.
Update 2011-06-08: A user in the comments, Moises, has pointed out that in the 6.x-1.0 release of uc_payafter there was a typo that would prevent users from being able to select the request shipping invoices in the conditional actions configuration. I have updated uc_payafter below to fix this bug.
Update 2011-11-08: uc_payafter has a new home! I have created a Drupal Sandbox project for the code here. Once I have the chance to work on the code a bit more, I will promote it to full project status and update the download links in this post.