Wednesday, April 4, 2012

Adventures with WAMP and XAMPP

I'm experimenting with AppFlower -- a rapid (?) application development (RAD) tool based on PHP and the Symfony framework -- as a possible solution for a non-trivial web application project in my college.  AppFlower/Symfony supports the MVC pattern for software development, which fits with our current practices.  I'm cautiously optimistic that it will work for us, and if so I may report back here.

The plan was for me to install it on my laptop this afternoon and then go through a tutorial or two.  I already have it running on my office PC (Linux Mint) in a VirtualBox virtual machine, but I prefer to use my laptop for development, since (a) it's faster than my somewhat antiquated office PC and (b) it's portable.  Also, I'll be working with one or more of our IT people, who are all slaves to Windows.  My laptop dual-boots Windows 7, so I figured I'd use the Win 7 side as my development environment.

As someone (Napoleon?) once said, the first casualty in every battle is the plan.  It took me 4.5 hours just to install on my laptop.  I don't need a virtual machine to run AppFlower under Windows, just a LAMP stack (give or take the "L"), and their website gives detailed instructions on how to install AppFlower to work with WampServer (a.k.a. WAMP), a very nice way to load an Apache-MySQL-PHP development stack on Windows.  I already had WAMP installed and running correctly with other applications, so this would be easy, right?

Almost.  All the configuration bits seemed to go smoothly until the last step, which is to run a Symfony configuration script via the PHP command line interface.  There were a couple of hiccups here:
  • the script turned out to be a bash script, which Windows had no idea how to handle (solution: find the php.exe file in the WAMP directory hierarchy -- it's not added to the system command path -- and run it explicitly against the setup script); and
  • prior to running the script, I was told to tweak a setting in the php.ini file that might otherwise cause AppFlower some problems -- but there are actually two php.ini files, one in the Apache directory and one in the PHP directory (solution: once I realized this, I tweaked both the same way).
Then there was one major problem: part way through the configuration script, the PHP command line (CLI) program died (known to Windows as "APPCRASH").  Poking around, the culprit seemed to be a module named php5ts.dll.  I became very intimate with Google's search engine looking for explanations and fixes.  A number of people have reported a variety of APPCRASHes involving PHP and Symfony or WAMP or neither of the above.  Many traced back to having two different versions of PHP installed on the same machine.  I don't; the WAMP copy was the only copy.  Some were allegedly cured by a fresh download and install (alleging a corrupt initial copy).  That did not fix mine. Someone suggested adding '-c . ' to the parameter strings of a bunch of lines in a couple of .php files.  Once again, that did not help me.

Well, no point in spending another four hours recounting where that first four hours went. Bottom line, nothing I did prevented the APPCRASH, so I finally gave up on WAMP, uninstalled it, and installed the Windows version of XAMPP.  The instructions for installing AppFlower under WAMP also work, with minimal modification, for installing it under XAMPP.  Some of the changes are quite minor (WAMP's control panel gives you a direct route to edit Apache's httpd.conf file, while in XAMPP I had to find it and open it manually in an editor).  The only sticking point -- and this is strictly a consequence of my brain being fried by the time I got to it -- was that the virtual host set up in Apache for the AppFlower Studio app did not work.  This was a copy/paste operation (copy the Apache directives from the instruction page, paste into httpd.conf.  Well, with WAMP it's copy/paste.  With XAMPP it's copy/paste/edit, because (duh!) the paths are different (C:\wamp\www becomes C:\xampp\htdocs, assuming you use the default installation paths for both). Interestingly (to me), AppFlower Studio will not open without the virtual host declaration.  (I thought I could just give an explicit path to it in the URL.  No such luck.)  If I have to do this again (heaven forfend!), this page will hopefully remind me to fix the virtual host declaration.

So I seem to be up and running now, albeit too late to touch the tutorial today. XAMPP seems to be using a more recent version of PHP than WAMP was; perhaps that explains php.exe not crashing on the Symfony script, or perhaps it's something entirely different.

Oh, yes, note to self: the user name and password for both AppFlower Studio and the SeedControl demo that it comes with are both 'admin' ... which is not well documented, to put it mildly.

Update:  Part of the AppFlower installation process is to add a VirtualHost directive to XAMPP's Apache configuration, so that the "host" name studio.local (which I mapped to 127.0.0.1 in the laptop's host file) points to the AppFlower web directory.  This worked, but too well: it masked XAMPP's own document root, to the point that the built-in administration interface was hidden. The explanation is found in Apache's instructions for name-based virtual hosts.  To avoid masking the original root, I need to add a second VirtualHost directive, using the original server name (in my case, localhost), point it to the original document root, and put it ahead of the one for AppFlower. (The AppFlower installation documents neglect to mention this.)

Update #2: I also need to insert a  NameVirtualHost directive in httpd.conf, ahead of the first VirtualHost directive.  Otherwise, the first VirtualHost (localhost for me) masks the second one (studio.local).

Update #3: Apparently, when installing on XAMPP and WAMP, AppFlower Studio needs to be told where to find the PHP executable. I fixed that, but I'm still getting error messages on most operations. They may be harmless, since the allegedly errant operation seems to have worked (possibly after manually refreshing the web page).

Update #4: I've given up on AppFlower with XAMPP/WAMP and may be having some success with VirtualBox (next post).

3 comments:

  1. It's pretty much a waste of time to bother installing AppFlower on wamp/xampp/xampp for the linux.

    Most people will redirect here to get some insight concerning the installation procedure, so I thought I would shed some light to people about the installation mess that they require you to undertake when trying to get it onto the localhost.

    I wouldn't necessarily say that they made it particular tough for people to install locally, but considering that it uses certain frameworks on top of other pieces of software, makes this a pretty complex procedure. I assume that this is also probably another way in which they get you to use their 'online version' for free for 14 days. If you're a quick learner, you could probably work through a tutorial and actually build something in 14days, otherwise it's like 49 dollars a month.

    So you've managed to get xampp installed (it's the fastest way to get it onto both windows and linux). Firstly, the instructions make use of a wamp/lamp style setup, which means you'll basically need to edit most of the cookbook tutorial to actually get somewhere.

    After doing the basic cookbook style procedure, you then need to use the symfony afs:init command to get it going. You're most likely not going to have this work unless you explicitly use the php.exe file under C:/xampp/php and then you must use a command like:

    php C:\wamp\www\appflower_studio_playground\symfony afs:init

    (the command only works for windows, linux is a complete dud and I'm yet to receive a forum reply concerning it) You'll actually see the processes being run in command prompt thinking it may have worked.

    After restarting the server and then going to:

    studio.local

    I ended up with a 500 error.

    I'm pretty much giving up on appflower for now. It's painfully sad that something that is supposed to make developing apps is actually so tough to get to run on your own.

    I'll probably come back to it someday when there's been major improvements (hopefully they'll raise some capital and improve the software and installation I've never gotten passed) but for now, even though the 'idea' of RAD sounds impressive, I think it makes more sense to limit the number of dependencies and instead focus on a core piece of software.

    I do wish them all the best though, considering that they actually bothered to open source it so that other people can actually use/build it, but if you're somebody that is looking for a drag and drop RAD tool and you have very little experience in command prompt and other complex setups, I would try the online version of this and avoid installing it at all.

    *Note I haven't used the VM version of appflower, but I'm not going to bother downloading a 1.4 gig file only to encounter the many errors I see other people are even with the VM version.

    ReplyDelete
    Replies
    1. I made a couple of typing errors:

      First line: supposed to be .../xampp for linux

      I'm pretty much giving up on appflower for now. It's painfully sad that something that is supposed to make developing apps EASIER AND FASTER is actually so tough to get to run on your own.

      If there are any others I missed, you can fill in the blanks for them.

      Delete
    2. Sorry to see that your luck was no better than mine. I no longer need to develop web apps, so I don't have much incentive to track AppFlower, but I do hope the developers resolve these issues. As you said, I appreciate their willingness to open-source it, and the effort they've put into developing it.

      Delete

Due to intermittent spamming, comments are being moderated. If this is your first time commenting on the blog, please read the Ground Rules for Comments. In particular, if you want to ask an operations research-related question not relevant to this post, consider asking it on Operations Research Stack Exchange.