I recently switched from the Jawbone Up to the Garmin Vivosmart fitness tracking band. Here's my review.
ModX Revolution is a pretty slick content management system for non-programmers. But, it has a few issues.
For one thing, you cannot take a website developed on one server and drop it into another server without re-installing the framework completely.
More importantly, it has seriously aggressive caching, that sometimes is counter-productive. My photography site is accessible from more than one domain name running on nginx. I found out the hard way that if someone accessed it by one domain name and then someone else by another, the first to the cache would generate links that had the full url to the first domain name in them. For most sites that's not a problem but when you're running JSON with a reactive website, the links that are crossing domain names will fail to work due to security settings in the server and browser.
I ended up doing what I probably should have done the first time which is redirect all requests for one domain name to the main one automatically with the web server.
ownCloud is a great way for paranoid people like me to run their own Dropbox-like service. It allows you to host your own files on a server that you can easily sync between desktops and mobile devices, and it's completely cross-platform!
The biggest challenge though was that documentation for how to run an ownCloud client on a headless Linux installation that doesn't have X installed is few and far between. But, it turns out it's really easy to do!
First, simply install the ownCloud client on your Linux headless server that you wish to sync it's data with your ownCloud server. It will install a few dependencies, but not a full Xorg installation so nothing to worry about.
Next, create a config file somewhere in your home directory. I created it as:
In that file put something like the following:
[General] [ownCloud] url=https://my.cloud.url.com/ http_user=tony authType=http user=tony
Obviously replace the URL with the actual URL to your server. Honestly though I'm not even sure it's needed.
Create a local directory that you wish to use to store your ownCloud files within:
Here's a guest blog post by Matthew Burkett on configuring the Merlin router firmware for OpenVPN.
So starting from the point of opening the box or using the reset button, when you first power on the device you will need to enter the basic information. Secure username and password for the router login, wireless SSID (Name) and password for both 2.4 and 5 Ghz channels, and your internet connection info if it was not automatically detected by the router. At this point you should have a fast useable router with great wireless coverage, if you are a standard user congratulations your done. Get on face book and tell your friends, if you are like me however you have only just started.
Merlin firmware installation
I've been fighting with Gluster with geo-replication on ZFS for several months now but I believe I've finally stumbled on the configuration that works best and gives much better Gluster performance on ZFS.
First a peek at the landscape
I probably don't have your typical storage needs. On this particular cluster I'm storing around 15 million files averaging 20MB each. No more than 255 files or sub-directories in a given directory.
My Gluster configuration uses a two-brick configuration with replica 2 (mirroring) and a single geo-replication slave over SSH.
Each Gluster brick uses ZFS RAID-Z volumes, spanning four SATA3 7200 RPM drives, and a single 256 GB SSD configured as a cache drive for the volume. Each Gluster server is connected on a private gigabit network segment to each other, and for the initial data load the Geo-replication server was connected to the same segment.
The Geo-replication slave also uses ZFS RAID-Z, but does not have a cache drive.
The goal with this configuration is to enable snapshot backups on either brick, plus geo-replication backups to a distant datacenter.
A friend of mine has switched to Elementary OS and claims it's the best Linux desktop he's ever used. Debian / Ubuntu based but with a lot more focus on the user interface and making it both pretty and useful. http://elementaryos.org/
Is it time for Canonical to lose the Desktop Linux battle? Perhaps, as they seem to be diverging more and more from what the average Linux user want's to see. Unfortunately they seem to have missed that no matter how much you try to dumb down Linux for my Grandmother, 99% of Linux users are still going to be geeks, or have an install that is set up by a geek.
Maybe with Valve moving more towards Linux with SteamOS and porting their game platforms to Linux, and with Electronic Arts and Dice occasionally wanting to mention the word Linux so they don't feel left out, you'll see more mainstream adoption. I imagine we will go through something similar to Android - different vendors may try to push their own "versions" of Linux branded for them, just like Valve is doing with SteamOS.
I finally got around to setting up my Canon MG5220 printer / scanner in Ubuntu. It was a little challenging just because of a couple of settings and obscurity around how to use it in Linux.
First, using this old article, I was able to find, download and install the drivers.
The kicker in Ubuntu 13.04 is that they've pretty much nerf'd the printer administration system. Thankfully this printer plays nicely, once you change a setting.
After turning on your printer and attaching it to the wifi, you need to go to the web interface on the printer at http://[printeripaddress]/
Next, click the "Other Settings" button in the bottom right of that page.
Then, click "Network Settings" and change the "LPR Service Notification" to "On".
To recap this page you should see something like:
Once that's done go and add a printer and Ubuntu should find it automatically. If you've followed the steps to install the driver in the blog post linked above, it will find the driver automatically.
I've been doing it all wrong.
As most seasoned developers know, making an application that works for many countries and languages is pretty much a requirement of modern software development.
And I've been doing it the hard way...
So, here's a snippet to get today's date in Android into a string that is formatted for the local language. Now, those not in the know may be thinking "A date's a date, right?" Wrong. American's have most things backwards. Dates are one of them. We're just so insulated that we don't realize it. For instance, today's date in the great USA looks like "10/3/2013" but in most European countries it would look like "3-10-2013" - progressing from smallest part of time to the largest.
So here's that snippet I promised (if you're in the UK, is that "promized?"):
Calendar c = Calendar.getInstance(); String mydate= android.text.format.DateFormat.getDateFormat(context).format(c.getTime());
DateFormat in Android will automatically structure the string in the way it's needed for whatever localization settings are on the device. Now you know. Yes, I'm slow to this, but that's ok.
So my latest app, Photog Companion generates PDF documents on Android.
I was thinking about supporting mark-up of existing PDF's. That's probably not all that difficult to implement myself but I don't want to spend the time learning the rest of the PDF spec. So, I did some research and even though a lot of people were saying bad things about the company I decided to contact iText to see what a license would cost. I was expecting something like a $500 developer license.
For my free application, they basically wanted from $0.17 to $0.55 per device installation. That means the more people that install my free application, the more I have to pay iText. Given even a low of 15,000 installs after a year (MilesTrac Free beat that) I'd owe iText a total of $2,650.
That's just nuts. It's about time someone wrote a PDF library for Android that's Apache 2.0 licensed. Maybe I should fork Apache's own PDFBox and start porting it to Android.
The Google Play Store interface for publishers was repeatedly telling me that I needed to design my application, Photog Companion Model Release, for Tablets.
The confusing thing for me was that I already provided alternate layouts for tablets and went to great pains to make sure it worked nicely on tablets.
It turns out, they require the new Layout folders "layout-sw600dp-land" and "layout-sw700dp-land" for compatibility with 7 and 10" tablets. Simply using "layout-xlarge-land" wasn't enough.
Quick and easy fix, just copy the layout I'd already made into the newly created Jellybean specific folders and the warning went away.