As of today Maximus, the BlitzMax Module Manager, has been taken down. I’ve blogged about this some time ago and today I’ve decided it was finally time to go through with it. The website now redirects to the GitHub organization that hosts the code for the client and the website. These will still be available online of course.
So what does this mean for Maximus and BlitzMax?
- The Maximus client can no longer fetch the sources file from the Maximus website and thus it can no longer download modules from the website as well. You’re back to downloading and installing BlitzMax modules manually yourself. If you’ve got a Maximus webapp instance running somewhere you can however configure the client to use the sources file from there.
- Development on both the client and webapp had stopped some time ago, but I would still fix bugs if they popped up. With the cancellation of the hosted webapp this also means I won’t be doing any development on Maximus anymore.
- With the source code being available anyone is free to host their own Maximus instance. Since the webapp uses Vagrant and Puppet you should be able to get a local instance running quickly. There’s also an INSTALL file for manual installation on Ubuntu.
Developing Maximus and providing this service has been a fun ride of which I’ve learned a lot and resulted in a well crafted piece of software. I can however no longer provide the service and support it and so it’s time to move on. I want to thank everyone who has supported Maximus in any way possible. Thanks.
A couple of weeks ago I talked about the future of Maximus and said that I would inform you about my decision once it was made. I’ve come to a decision about Maximus and have decided that I will pull the plug on it. I just don’t know when yet.
For the time being the website will stay online but I’m no longer making an effort in keeping it up and running. As soon as I need the server resources that Maximus is currently taking I’ll be shutting it down.
There’s a slight chance I’ll move Maximus to my local homeserver which isn’t always available. The only reason I would do this is so I’ll still have a hosted module repository in case I want to use BlitzMax again. But considering I haven’t touched the language in a while I’m not sure yet.
Lately I’ve been thinking of Maximus‘ future. I’ve had a draft blog post with the title ‘Pulling the plug on Maximus’ poking me in the face for at least 6 months now and I’m still not sure if I should be writing it or not. I’ve got a number of reasons to end the project but also to continue it.
Reasons to pull the plug would be that I no longer use BlitzMax and thus it’s wasting precious server resources. I’ve also got little time for maintaining the codebase (it’s stable software, so not much going on there though) and keeping the service running. Furthermore I’ve got no clue on how big the Maximus user base is. I know a couple of BlitzMaxers (though it seems they’ve moved on from BlitzMax) who use Maximus, but that’s about it. As far as I know it could be 5, 10, 100 or 0 users. Aside from the users there has also been little participation from module authors.
There are also reasons to keep the project alive. It’s still one of the coolest things available for BlitzMax. It’s a big central repository with almost all available BlitzMax modules and currently there’s no other solution for easily installing your desired BlitzMax modules and their dependencies. It’s also a stable code base and the way it’s running now doesn’t require much maintenance. I’ve still got plenty of ideas to implement and improve Maximus as well. It can also be a nice playground for trying out new technologies. One such example was adding Vagrant support which is something I now use on a daily basis.
Still, I’m more and more feeling like ending the Maximus project. It no longer scratches an itch of mine since I’m not using BlitzMax anymore and like I’ve said I’ve got no clue if other people actually use it. Sure, from time to time I can find an entry in my log files that shows a module has been downloaded, but that’s about it.
For the time being I’m going to think about what my decision is going to be. Once one has been made I’ll inform you again on my blog. In case of termination I’ll inform ahead of it. Comments and suggestions are more than welcome.
I’ve been using tmux for a while no to manage my terminal sessions. One thing I kept on doing was after starting
tmux that I would be manually adding windows, splitting them and issuing commands in each pane such as echoing the contents of log files with
I had heard about scripting
tmux before but never really looked into it yet, until now. Since I solely use the key bindings I had to figure out how to issue these commands without them. Turns out this is pretty easy and it’s documented in the man page.
Here’s an example of a tmux script I just added to Maximus-Web.
tmux -2 new-session -d -s $SESSION
# Setup a window for tailing log files
tmux new-window -t $SESSION:1 -n 'Logs'
tmux split-window -h
tmux select-pane -t 0
tmux send-keys "tail -f /vagrant/maximus.log" C-m
tmux select-pane -t 1
tmux send-keys "tail -f /vagrant/maximus-worker.log" C-m
tmux split-window -v
tmux resize-pane -D 20
tmux send-keys "tail -f /vagrant/maximus-mojo.log" C-m
# Setup a CoffeeScript compiler/watchdog pane
tmux select-pane -t 0
tmux split-window -v
tmux resize-pane -D 20
tmux send-keys "coffee -o /vagrant/root/static/js/ -cw /vagrant/root/coffee/" C-m
# Setup a MySQL window
tmux new-window -t $SESSION:2 -n 'MySQL' 'mysql -uroot'
# Set default window
tmux select-window -t $SESSION:1
# Attach to session
tmux -2 attach-session -t $SESSION
You can view the (up to date) origin of this script at GitHub.
So what exactly does this script do?
- It creates a new tmux session.
- It creates a new window called ‘Logs’ which is split into a grid of 2×2 with the bottom 2 panes being smaller in size (height). In every pane a command is executed. For example in pane 0 the command
tail -f /vagrant/maximus.log gets executed.
- A second window called ‘MySQL’ is created which runs the
mysql -uroot command.
- Then we switch back to the first window (actually second, as tmux pane numbers start with 0) which is the window that shows us the contents of these log files.
- Finally we attach to the tmux session.
The added benefit of this small script is that from now on all I have to do is run it and my tmux session will be configured for this specific project (Maximus in this case).
I’ve also found some other useful tmux resources as well which are listed below:
Using HTML2PDF Web Service
you can design in HTML and CSS, and convert the resulting page to PDF. Free trial available!
I thought it would be nice to start a series of posts on neat tricks and plugins for Vim, called Vim Essentials. I don’t know how often I will do these kind of posts, but I’ve got a couple in mind already.
This first post I’ll start off with Powerline. A plugin for Vim that gives you a better status bar than the default status bar. Your current mode, filetype and used file format is more clear. See the picture below for an example.
After you download and install Powerline you also need to make sure that your
.gvimrc has the following lines:
set laststatus=2 " Always show the statusline
set encoding=utf-8 " Necessary to show Unicode glyphs
Adding these two lines makes sure the status bar is always being shown and the characters used in it can be displayed.
Looking at the screenshots provided by the author of Powerline it should also be possible to display the current Git branch, but I’ve yet to find out how to do so. The version I’ve linked here is deprecated in favor of the Python rewrite, which can be found at https://github.com/Lokaltog/powerline.