Hacking Computers, and the Net

I had mixed results following The clojure-doc tutorial for Emacs, and found I had to do a few modifications. Following the recipe is easy: I was not able to easily get Aquamacs to work. Frankly, I lost interest after the initial try, and just went with the emacs build for OSX. I might mess with Aquamacs at some future point, but for now, let's just stick with Emacs proper. Install Emacs from brew First, set up Emacs from brew: $ brew install emacs --cocoa --srgb $ brew linkapps Emacs NOTE If you already have Emacs in your Applications folder, the second brew command will fail. To make sure we're on the same page, just rename Emacs.app to something else, like EmacsCocoa.app or whatever, then re-run the second brew command to link the Emacs distribution you just installed with brew to your Applications folder. After it successfully runs, you'll have a link in your Applications folder called, "Emacs". Clicking it will open the GUI version of Emacs.

I was given an interesting challenge to scrape some data from a specific site.  Not to write a completed, packaged solution, but rather just to scrape the data.  The rub being, the site uses Javascript paging, so one couldn't simply use something like Mechanize.  While a self-contained product would require inclusion of V8 (as the Javascript would need to be run and evaluated), to just scrape the data allows making use of whatever is easy and available.  Enter Watir . Watir allows "mechanized/automated" browser control.  Essentially, we can script a browser to go to pages, click links, fill out forms, and what have you.  It's mainstay is in testing, but it's also pretty damned handy in cases where we need some Javascript on a page processed... like in this case.  Keep in mind though, it is literally automating a browser, so you'll see your browser open and navigate to pages, etc. when the script runs.  But, there is also a headless browser option.  This is

You must have Command Line Tools installed. If you don't , this tutorial is not for you. Google: installation of XCode and Command Line Tools. Normally, I use brew to install things (when it offers a solution), but in this case the keg version was a couple minor version's off. And, there had been sufficient addition's that motivated me to want the current release. So, building from source was the path of least resistance. First, what not to do : The note's caution against using OS X's Terminal , as their make.sh script pukes a shit-ton of text during the build, and according to them, it can slow the build. I did not experience an issue with this, compared to other builds I've done in the past.   BUT , they also say build can be accomplished with other LISP's installed (you must have a lisp installed prior to building). OMFG , unless you want to wait a month of Sunday's, my experience building with CLISP was slower than the Molasses in January.  D

I have had several occasion's where Java apps would open, and then immediately close.  Often, I don't have the time to dig into the reason, as they aren't crucial.  So, I just move on. Recently, I was maddened by this happening to an application ( see other blog post on Kindle Previewer ) I really needed to use, so I had to get into the trench.  After cracking open the app, and rooting through the various files, I did some spot-checks of the java version used to build the jars ( 2 bytes at offsets 6 & 7 ), as well as had a look at the info.plist, which had the JVMVersion key set at 1.5+. Since Oracle took over Java, Apple has essentially abandoned it to them, and hasn't done an update I *think* since version 6. All of Apple's Tooling for Java stops with JVMVersion key's of 6* and 6+.  The short answer to all this is, if something was built using Apple's AppBundler tools, and you have updated Java on your Mac to 7 or above, you're probably SOL to g

So, I've been a big Erlang fan for a few years now, and then found out about Elixir :  what I would describe as kind of a Ruby -ish creamy frosting on top of Erlang . But I'll address more on both in future. Right now, I thought I'd just give a quick and dirty way to add Elixir , if you've already got Erlang installed (hint: check-out this Erlang Solutions link for a pre-compiled Erlang solution).  You can also use brew to install both , but I have found that with the simplicity of brew, you give up having the most current version of software.  In both cases. The pre-compiled zip for the most current version of  Elixir can be found here .  Unzipping reveals a folder containing everything you need.  For simplicity's sake, keeping everything pertaining to Elixir all within this folder makes the most sense.  By doing so, all that's needed is to position the folder, and then make links to all the executables in a directory already in our path.  Through t

So, after a serious pain in the butt getting Boost installed using the homebrew boost keg (see my previous post ), I decided to test things out using AppCode. Obviously, since this is a "3rd party library", a little massaging has to be done to get the libraries and headers found, and it's sufficiently obscure to deserve a post. I will list the procedure using my rig (OS X). You can extrapolate from this to your own kit. Right-click on your project icon, and select, "Project Settings..." , and scroll down to the "Search Paths" heading. About the third or so option down is "Header Search Paths" . Open that, and select either or both your type of build (Debug/Release), and then double click to the right of it under the "value" column. This will open up a window where you can add a path. Click the "+" and enter the path to the location of your copy of Boost's Headers. In my case: /usr/local/Cellar/boost/1.

I was installing boost today using the *brew keg*, which shows it's for the latest version, 1.55.0, but I kept running into errors. --HEAD --with-mpi In the case of #1, it kept puking every time it tried to grab boost from svn. In the case of #2, no matter what I did, including this option kept giving a warning about Python support soon to be deprecated. And yes, I tried the --without-python` option. It just wasn't happening. I don't know if it's a problem with the keg, or a problem with this particular build of Boost. Finally, I was successfully able to get things to build using: brew install boost --c++11 --with-icu --without-python --without-single

OS X is of course a variety of BSD Unix, not Linux. Often is the case where Linux commands either don't work, or don't give the same results on OS X as they do on Linux. For example, a basic netstat will give you a long list of the processes making network connections on your box. On Linux, various command line options can help you drill down from there, to get the answers to more specific queries. On OS X, those same queries don't give you the answers you're seeking. This isn't a compare and contrast article between Linux and OSX. Instead, I'm just noting various commands that can give answers to some basic questions. On OS X, for example, to get an answer to the question: "What process is running on port 50224?" we would use: sudo lsof -Pn | grep 50224 This will give you a list of everything connected to port 50224, sans any kind of headings. A much more abbreviated command that will give you essentially the same things, but with column

Besides running a local copy of Apache on Nginx or your dev box, or using *vagrant*, the only other alternatives for a long time were XAMPP, MAMP, etc. While there are certainly good arguments for using them, for folks like Web Designers and such, there are a lot of technical hoops to jump through that just aren't needed for these types of use cases. And, there are times as well where we coders might want to throw up some flavor of CGI scripted code, and not have to mess with any of the above. Along come two excellent solutions, one completely Open Source, the other Open Source enough for the above use case. In fact, the completely open source solution is a fork of the other, prior to its changing its license to GPL. What I'm talking about is: Mongoose Civetweb Basic Rundown The Mongoose Docs will cover all the nuances, but basically, you can download the .dmg, open it, drag the app where ever you want to run it from, and double-click it. When the app op

So the problem is simple. We're developing one, or a number of sites on our development box. We would like to be able to hit them in our browser via their url names, rather than various permutations of ip number and folder structure. I do my development on a Mac, so this solution is for OS X. The first step is to go into: /etc/hosts in a text editor, and assign the url to the loop-back address (you can just put it under all the other entries): 127.0.0.1 my-ghost-blog.com No that this is done, we next need to flush our dns cache using the following command in the terminal: dscacheutil -flushcache OK, now we can go to: my-ghost-blog.com in our web browser, and it will bring up our local running instance of ghost. --- This is a well known problem, and has a well known solution. The more of these solutions there are across the web, the greater the chance they will be found by any number of different key words.