PHP5 as the Current Best Mini Web Server

Quite often today ... especially in cloud environments or cloud-like settings (will not explain the latter term), you want to do away with the traditional Apache (or LightHTTPD, etc.) + PHP setup in favor of ...


-- a small,
-- portable
-- PHP-capable
-- web server.


The following figure will show you a standard usecase for such a setting.

You have 2 locations that need to talk to each other over HTTP. Since basically all cloud (and others as well) APIs today are HTTP -- or RESTful if the use a fancy word, this is quite a common case. The easiest way to do this is:

(1) To use wget (here is a link for Windows native version but I personally use Linux and cygwin versions) when you need to initiate a request to the other side, and
(2) To listen to requests from the other side using your mini web server.

Never mind the ports and all such details. What's important is the model used by the pair to communicate in both directions.


Now, specifically about PHP. This is a crucial element. I hear some people still use Java. I have nothing against these people but my personal opinion is that PHP is a much better .. flexibility and otherwise ... programming environment. I migrated to PHP 7-8 years ago and never doubted this decision.


Now, you might think that there is a whole bunch of mini web servers? Nope. Even Nope-i-er when it comes to Windows. I personally went through:

- TinyWeb Server -- it has a PHP version which simply does not work. It does run but you cannot get $_GET, $_POST and some other important stuff to work. Was very disappointed because this was the most promising version.
- XAMPP Portable. There is nothing portable or mini about this server as it is half-a-Gigabyte when decompressed. Could not get it to work either. First, Apache complained, then PHP did not run, etc. Had to quit on that one, too.
- Lighty2Go. Very promising name. Very disappointing results. Specifically no PHP support.


To cut a long story short, the solution was in plain sight since PHP 5.4.x was released. This version of PHP has a mini-server mode. Have been using it for a week now and have had zero problems. After all, it is about time PHP found out a way to serve its scripts without needing to go through Apache.

To run the server, you simply run:

php -S localhost:[YOUR PORT like 8001, etc.] -t /path/to/web/root

Some side notes on the convenience of this solution:
(1) I already have PHP everywhere. Windows native, Windows/Cygwin, Linux, virtual machines, added to XCP hosts, etc. Meaning that I get the server without any additional work.
(2) Easy to start and stop it. Temporary solution is exactly what we need in cloud applications. You never have anything permanent.
(3) PHP Server can now become a command line tool like wget. Again, simpler to understand and use. I enjoy having access to Cygwin environment while running the server.



Strongly recommended.

StackEdit for Markdown (.md) in Google Drives ... kind of works

UPDATE 2014/01/22 later that day. -- it looks like it still works but there is now a checkbox in StackEdit settings that says "Markdown Extra/GitHub Flavored Markdown syntax". If it is ON, the HTML inside .md is ignored. If you UNCHECK it, it works as is described below.

UPDATE 2014/01/22 -- This kind-of-works has recently turned into does-not-work. StackEdit obviously stopped recognizing HTML mixed in with your .md text. I used to have pretty looking pages and now they all reverted to custom format. There could be a workaround -- possibly adding the STYLE tag into the templates in StackEdit setting. I will try that later.

====

Yep. Kind of works. Meaning that it does work entirely satisfactor... torrrily .. is that a word? ... but has some flaws when it comes to sharing.


Specifically, PROS:
--------------
- you can work with content which is viewable in browsers. Literally with HTML. You do not have to type in HTML because .md has some custom behavior based on some syntax you use in text (do a search on markdown), but if you do type in HTML it will interpret it correctly;
- it is easier when writing notes (meeting minutes, manuals, etc.) when its closest rival -- Word, including the one in Google Drive. I hate to type docs I create on the fly in Word. See the example below for an example *pretty doc*.
- Print-to-PDF is excellent! Keeps all the formats, colors, etc. These docs are pretty!


Now, CONS:
----------
- a bit sluggish because it is not native to Google Drive
- viewing mode is one button away but the default is a split screen (input versus WYSIWYG) -- not good when you share your doc with others
- sharing is painful. Even if your share-ees have Google accounts, they have to walk through the installation process to enable StackEdit on their accounts. The biggest pain is that people who do not have Google accounts cannot view your .md docs ... at ALL. I still get a couple of those among my friends. Ended up creating a PDF for the file and sharing that.


Now, this blog is on a specific topic related to .md files. Default .md behavior is not what you might expect. For example, H1 is too big with huge margins, there is no italic, now underlined text, etc. However, including a small STYLE section at the beginning of your .md file will take care of all that. Think of this as a FORMAT stab which you an copy across a subset of your documents.

Here is mine:

STYLE -- enclose in angle braces as is normally done in HTML
em { font-size:larger; font-weight: bold; font-style: normal; text-decoration: none; }
strong { font-size:larger; font-weight: bold; text-decoration: underline; }
h1 { margin: 20px 0px 5px 0px; font-size: 20px; font-weight: bold; background-color: #ccc; padding: 3px 0px; }
h2 { margin: 20px 0px 5px 0px; font-size: 20px; font-weight: bold; background-color: #f00; padding: 3px 0px; color: #fff; }
code { background-color:#ccc; }
hr { border: 1px solid #999; margin: 5px 0px 10px; }
/STYLE

It looks like this in on the left size of your StackEdit:

And like in WYSIWYG on the right side (one of my current docs):

The syntax the style of which I altered is:
1. `code`
2. *stress*
3. **more stress**
4. # normal header/section
5. ## red header / section

For the rest of default syntax see a Markdown howto.

NiceCover: A Serverless Webapp for Crowdsourcing Data Extraction and Knowledge Generation on Top of Scientific Portals

The title is a mouthful, I know. But you need that long to describe the idea.

There is a story behind it. I have first-hand experience in how major scientific portals (won't tell you which one exactly) upgrade their portals. Not good, my friends, not good ... are the processes and routines these people use.

Anyway, NiceCover is literally a nice cover for the scientific portals. The target is:

(1) Build a social collaboration layer on top of scientific portals.
(2) Write serverless webapps.
(3) Make sure you are within terms of use, but go wild otherwise.

These slides report on the first step.

There will be more soon.

StopWastingFoodAPI

Now, is it really that difficult to solve the problem of 2/3 of the product wasted at our supermarkets?

Social Applications that Live in Clouds and Help People Link Their Work

Social Application are not Social Networks, especially not those that are popular today. Social apps are simple applications which do work socially -- normally by facilitating social collaboration. Note that there are not such apps today.

You can see my previous posts about social collaboration here and here. In fact, one app that welcomes social collaboration is still running in the wild ... wide open to the public .. with not a single client other than my own in these few weeks. Let's put social collaboration itself aside.

Consider this app:

It lives in the cloud because it is hosted by, say, Google Drive (or Dropbox, or some other) and keeps its output in the same place in the cloud it came from. In order to make it work you need two things:

(1) Solution to the Stringex Problem on which I wrote before, preferably a working software client.

(2) People willing to participate to form the three in the figure in the bottom-up fashion. Note that there are Miners and Mappers.


The problem is that (2) creates security problems. Specifically, people might be afraid to open up their data to public. This fear is not completely ungrounded. Dropbox API, for example, opens your public spaces wide open which means that anyone with the keys can overwrite, erase, add, or do anything with your data. Which is why most such apps limit their scope to the Dropbox account of the user him/herself. You basically write to your own account. On the other hand, Social Apps NEED to share their public spaces.

Still can be done. As long as you provide a separate PRIVATE space which no one can touch and develop a SMART SYNC. The smartness of the sync should be judged the same as Wikipedia does it -- it should be much easier to revert malicious changes than to make them.

Open problem which I am currently trying to close...

The Stringex Problem: Client-Side Indexing in Clouds

Hadoop and Lucene-style indexing all sound nice, until you stumble upon a new practical usecase (read: problem) and need to build a webapp which needs indexing on the client side (read: browser) in realtime (read:continuously). That's when you run into the Stringex Problem. Hint: When you need to access the data you keep on the cloud, you need to mind the size of the hole through the membrane (read: API capability).