Hey there, I'm Shanif! I'm working in the tech field and have a background in technology, analytics, startups, and even options trading. I've been developing software since 1997, working in startups since '08, and started trading options in '09.
I have a BS in Computer Science and Information Systems Engineering, and an MBA (specializing in Quantitative Finance and Entrepreneurship & Innovation). These days, I'm working on product analytics at Twitter after they acquired a mobile ad company I helped build after b-school. Come say hello!
People, Places, Things - My Best Shots
New Solution For WordPress “White Screen of Death”
I’m in the process of rebuilding Intigril’s website, and as I do so, I have to tightly integrate the Rails and WordPress pieces of it. One of the issues I was recently having was the WordPress “White Screen of Death.” This is a problem that most WordPress managers have probably seen at one point or another.
You try to go to your WordPress homepage and the only thing you see is a blank white screen. There’s nothing in the logs. There’s nothing in the source of the page. Just blank, white, death (thus the name). Doing a quick Google search shows that thousands of others have experienced this problem. Like any other technical issue, there are a variety of causes and solutions (bad plugins, extra spaces at the end of files, messed up wp-config.php files) – all of which I tried to solve my current issue, and all of which subsequently failed.
After going through a whole day’s worth of efforts, I read through a couple of forum posts on my web hosts’s support site and realized that they may have to make some entries into my Apache vhost file (since I am running WordPress as a subdirectory of a Rails app that is running on Passenger).
When I contacted them, they gave me a one line, extremely simple answer. As far as IT things go, these are generally the best solutions, and in my case, it fixed my issue. All I had to do was put PassengerEnabled off in the .htaccess file of my WordPress root directory.
As soon as I did that, both the homepage of my WordPress installation as well as my admin login page came up without a hitch. Hopefully this will help those of you out there that are experiencing the WSOD and are seeing no success with the other, more common solutions out there.View comments →
Getting Tidy To Work On 64-Bit Linux Systems
For one of the tools I’m making for Intigril’s new site, I need to do some scraping and parsing. There’s a great Rails plug-in for this called scrAPI. This plug-in uses a separate plug-in called Tidy. Tidy is used to clean-up bad HTML so that it’s easier to parse. A while ago, I wrote an application that utilized both of these plug-ins to do some extensive scraping and parsing. Everything was working fine until my shared host decided to upgrade their system (isn’t it funny how upgrades usually tend to break everything).
Well, they ended up going to a 64-bit server, which caused a whole lot of issues for me. It turns out that in order to use Tidy, you have to have the compiled binary for it loaded onto your system. scrAPI comes with that binary when you install it, but that binary is compiled for 32-bit systems. When you try to use it on 64-bit systems, you’ll get an error that says the file can’t be loaded. It’ll read something like this:
Scraper::Reader::HTMLParseError: Scraper::Reader::HTMLParseError: Unable to load /var/lib/gems/1.8/gems/scrapi-1.2.0/lib/scraper/../tidy/libtidy.dylib
It took me a while to figure out what this really meant, but ultimately, it means you’ll need to get a different version of the file “libtidy.so” – one that’s compiled for 64-bit architectures. This seemed easy enough – after all, all I had to do was find a file and toss it onto the server.
It’s never really that simple, though, is it?
It turned out that my host already had a copy of this file on their server (in fact, they had several copies of this file, which I found by using the command “find / -name ‘libtidy.so'”. Once I found the right file, I thought that all I’d have to do next would be to tell Tidy to use that file by setting the path in my production.rb config file, as such:
Tidy.path = "/path/to/libtidy.so"
When I did that, though, I got the following error the next time I tried to run my code:
/path/to/gems/tidy-1.1.2/lib/tidy/tidybuf.rb:40: [BUG] Segmentation fault
Things went from bad to worse. It turns out that this was a known bug, and there was a patch for it. You can see the details on this page. I read all of the posts on that page and made the following changes, as suggested:
- Added the line
"extern void tidyBufInit(void*)"to the ‘load’ method in the file tidy-1.1.2/lib/tidy/tidylib.rb
- Added the following method to the same file (Tidylib):
#tidyBufInit, using default allocator
- Added the following line to the initialize method in the tidybuf.rb file:
- Added the following field to the TidyBuffer struct:
I saved those changes into the version of Tidy that I had frozen to my Rails app. Once I made those changes and re-deployed my code, everything was working perfectly.View comments →
Getting XAMPP, Passenger, And Rails To Play Nicely On A Mac
Even though I’ll be switching into the world of sales and trading (and hopefully entrepreneurship) fairly soon, I’m always going to be a techie at heart. Ultimately, I think that will help my career. I’ll always be interested in developing applications to solve problems.
Most recently, I needed to install and configure Phusion Passenger and Apache on my Mac so that I could get to work on Intigril’s website. I wasn’t too worried about this, since everywhere I look, I read articles about how easy it is to install Phusion Passenger. Oh ye of too much faith.
I just spent the past day struggling with my system. Fortunately, I’ve been able to get everything up and running, but not without a lot of hassle.
The first thing I tried was installing MAMP on my Mac. That went off without a hitch. Then I tried to install Phusion Passenger. The installation went okay, but when I tried to start the server, it wouldn’t do anything. It turns out that Macs come pre-installed with Apache, and that when you install Passenger, it will get compiled against that version.
In order to solve this, the Passenger documentation site says that you have to export a certain environment variable. The website also clearly states that you need to open a “root shell” before running any commands, because using the “sudo” command will eliminate any environment variables you previously set. I didn’t read that part, so when I tried to install Passenger, it would never get installed to MAMP’s Apache, so when I made the necessary changes to my httpd.conf file, Apache would never start.
So I tried to compile Passenger against my native Apache installation instead. However, the problem with that was that I would continually get 403 Forbidden errors. I obviously tried “chmod”ding the heck out of all of my directories and files, but to no avail.
So the next thing I tried was installing XAMPP for the Mac and then compiling Passenger to that installation of Apache. I made the same mistake as before, so it obviously didn’t work. That’s when I took a closer look at the documentation and saw that I needed to switch into a root shell by using “sudo -s”. Once I did this and exported the correct environment variable, I was able to install Passenger into my XAMPP installation.
Following that, I updated my hosts file so that “intigril.local” would point to my local installation, fired up my web browser, and instead of my shiny new site, I got “Passenger Error #2.” It said something about not being able to “stat” the “config.ru” file in my Rails root directory.
I had no idea what this meant. I don’t even know what config.ru is used for. It turns out this was another permissions issue. The resolution was to update Apache’s configuration file with the following:
- Make sure the “User” that Apache runs as is not listed as “nobody.” I tried changing it to “www” but it still didn’t work, so instead I just used my own user account (hey, it’s just a dev box).
- Update the Virtual Host so that Rails runs with the correct username.
- Update the Virtual Host so that Rails has the correct DocumentRoot.
- Update the httpd.conf file so that it includes the module for virtual hosts.
This post helped a lot in getting through a lot of the configuration issues.
After I did all that, I finally got it working. The next step will be to get WordPress up and running as a subdirectory of my Rails site.
Wish me luck.View comments →
- Name: Shanif Dhanani
- Address: New York, NY, USA
- E-mail: firstname.lastname@example.org