Skip to main content

Development Server Alternatives

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:

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 opens up, it places a menu icon in your top menu bar of your desktop that you can interface with. The Civetweb Docs will again cover the details, but as a quick-start, download the .dmg, open it, drag the app to where you want it, double-click it, and it will place a menu icon in the top menu bar of your desktop. In both cases, basic usage is simple. After starting the app, open the menu and select: 
Edit Configuration
This will open the servers config file in your default .txt application for editing. Somewhere in the short list of items is: 
document_root
All you have to do is point that to the absolute address of the folder from which you want the contents served. Stop, then re-start Mongoose | Civetweb, and it will begin serving index.html (or index.php) from that folder on: 
localhost:8080
... so make sure that port isn't blocked from something else. However, if for some reason you want it to serve from a different port, not a problem. That option, along with a host of others, is available in the previously mentioned config file. These servers will also run Lua Server Pages, and even perl. So folks, if you don't already know about them, they are well worth checking out for those little/quickie jobs where going through the dance of a heavier stack isn't needed.
Labels:

Comments

Post a Comment

Popular posts from this blog

Codeigniter vs. Kohana Database access speeds

I was doing some basic profiling for a project in which I needed the fastest raw speed I could get with database queries. I'm a fan of Codeigniter for projects that are suitable for it, but had heard from some that Kohana was faster, so I decided to do a very basic comparison of the two. I was using MAMP for OSX, and created a very small db, with a table that had 3 fields: (id), (first), and (last). The data sample was also very small, only a few records. The basic query I tested was a "SELECT * FROM [table]". There is of course nothing remotely scientific about this. It was just a quick ad dirty, very limited comparison. Take it as such. Versions used: CI2.1.3, Kohana 3.3.0. Codeigniter I really like Codeigniter (CI). But, one thing that is very evident from their own profiling functions, is that CI is a bit of a memory hog! Essentially, the same Controller function running in CI takes approximately 10X more memory than in Kohana! This in itself is not ...
Post a Comment
Read more

Screen Scraping in Ruby with Watir and Nokogiri

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 opti...
Post a Comment
Read more

React Simplicity

This is just a quick intro to React to show how easy it is on a very basic level. React is often compared to Angular, but the two are very different: Angular is more of a framework , whereas React is more of a library . So, with React, we can make Components, and in so doing, we can intersperse plain Javascript to instill behavior. This article is not showing (or using) best practices, or a recommended structure. It's purpose is only to show how easy the basic mechanics of React are. Let's grab the getting started cli from React's page npm install -g create-react-app create-react-app my-app cd my-app npm start After this is done, and you have the project displayed in your browser, let's experiment. A boiler-plate header we can use for each new class can be as simple as: /src/Foo.js import React, { Component } from 'react'; class Foo extends Component { render(){ return(); } } export default Foo; So, all that we need to change to get st...
Post a Comment
Read more