I've recently purchased a Mac Mini with the only purpose of being a server.
I'm a C programmer, learning Lua and Obj-C at the moment. I'm trying to set up a website, a kind of CV/Personal Promotion site.
I've been looking at MAMP for a while however, I would like to use nginx and Lua in place of Apache and PHP.
My thought is using Lua instead of PHP would help accelerate my learning curve.
Does anyone have experience with this setup or using lua as server scripting?
Cheers
There is Jan Kneschke's lua magnet of which I maintain a fork on github. I use this in conjunction with FastCGI (and luasql.sqlite3) for a small message board, which was previously written in PHP, then python.
The PHP and python versions each performed so-so (which may be due to me not being a good PHP/Python programmer at that time), and each took about 10-40MB of RAM. The Lua version runs within 1MB and is measurably faster. Also the code is easier to read, IMHO.
Note that you will need some helper modules to work with POST requests. The download files to the book Lighttpd contain a version of cgi.lua that does the trick. If there is interest, I can make it available on my GitHub.
Related
I am experimenting JRuby on Rails and need some guidance/tips in choosing the server. I have used nginx (and passenger) for my RoR in the past. JRuby wiki page Servers provide a lot of options and I have no experience in any of them.
What I am looking for is a simple to install, easy to scale server or the one widely used (so that I can find solutions if I am stuck)
I do realize this might be a broad question and the answer would be "it depends..." but would appreciate some pointers.
I might be biased being on the Trinidad team, but I still think it's top ... esp. as it handles high concurrency well while still being much lighter than TorqueBox (which I would also recommend if you do want something beyond just a web server e.g. built-in jobs but be aware that some of it is TB/JRuby specific). Most other options mentioned are Java web servers, which you can rule out if you do not want to install a Java server, warbling your application and deploying it as a .war file.
p.s. for the (next) version 1.5.0 re-deploys are to be revisited and one should be able to do some (memory leak-free) zero-down time deployments.
I often find the quote "InstallUtil.exe" is an ugly pattern or "Don't use InstallUtil.exe" and that I should use native WIX or Installation package patterns and I still don't understood why.
I stepped away from using InstallUtil to install a .NET service as I finally learnt that writing registry keys for such an action should be an un-install-able action - and I've come to terms with this as correct.
As I've been working through my WIX installer for a relatively complex product, I have found myself in need of creating or updating SQL Server databases, creating or updating IIS Applications and finally updating or creating configuration files.
Each of my components (features) are optional, but they all share the same configuration file. As my product uses unity, its important to note that this library contains strong support for reading/updating/removing components from the Unity Configuration block, therefore it seems fairly smart to me that I should take advantages of these blocks via Installation Components (i.e. InstallUtil) to create or update my configuration file at installation time.
Just to be clear here, my installer does not natively contain a configuration file for my application: at installation time, the installer has no idea as to the shape of it as its based on the features selected. Surely I should be embedding this knowledge into each of the modules that are to be deployed and not in the remit of the installer which is now a completely independent project? Wouldn't this break O-O principals even if we are talking about installation?
I'd really appreciate some guidance as to whether this is good practise or not? Am I reading 'InstallUtil' is bad for installing services, or is it that using 'InstallUtil' is bad full-stop? If so, what are my options for smart updating of configuration files?
The main reason for avoiding InstallUtil is that it runs outside of the installation transaction, so Windows Installer cannot keep track of what it's done.
I have used InstallUtil on a few occasions, when I just couldn't get Wix to do what I needed and didn't have time to write a custom action. In this case I called the InstallUtilLib version as I feel this is a cleaner approach.
I used the this blog as a guide as to how to achieve this.
I have an existing website written in ASP.net, I have recently switched to Mac full time (With Windows in Boot Camp), and need to write a public API for accessing my website's MySQL data. I primarily want to use the API to allow building an iOS application.
I am interested in learning either Ruby on Rails or Node.js, I haven't used either of them yet.
Which language would be better for me to learn?
Rails is a relatively mature web framework based in Ruby and is designed for handling object-mapped data persistence in a relational database backend.
Node.js is much newer on the scene, and unlike Rails, is a more bare-bones package that allows for server-side Javascript applications thanks to a pretty tight HTTP(S) API. Node applications are by nature event-driven, which may or may not be ideal for your application.
Since it seems that you'll need data-persistence (you mentioned accessing MySQL data...), Rails might be easier to get started with, as it comes packaged with all the things you need in this respect and is designed to facilitate this sort of application.
If you you don't really need relational data persistence, Node is probably a better bet as it stays out of your way and lets you decide how to handle things. It's important to note that Node is a much more bare-bones "framework" than Rails -- if you want something slightly higher-level but still lighter than Rails that runs on Node, express is good place to start.
Still, if you want to try Node (I will confess: it's a lot of fun!), it's totally possible to access MySQL in a nice, event-driven (non-blocking) way. Here are two modules that will be helpful:
node-dbslayer
node-mysql
Neither is a language; they're frameworks. There is no "better", there may be a "more suitable" (probably not in this case).
Which would you prefer to develop in, Ruby (Rails), or JavaScript (node.js)?
Would you like to transfer that knowledge to a different job without rampup time (Rails)?
Would you like to learn something a bit more esoteric, event-driven (node.js)? (Ruby has Event Machine, but IMO node.js takes it a bit further.)
So this new application is just a middle man between your ASP.NET thing and your other clients.
In that case, totally use node. Node is great at being networking glue. Node scales great with IO bound applications (i.e. being a network middleman).
If you're going to use node then you probably want to look at express to make it easier.
I'm deciding between LAMP and Google App Engine with Python. Mainly this is an educational experience so I'm weighing the potential ease/quickness of developing on App Engine against the value in learning LAMP from the get go (and not being locked into the App Engine way of doing things
It depends on where you come from. If you're already familiar with either PHP or Python, I'd let my choice depend on that.
If you're starting from scratch, there's a few things to consider :
PHP (if you consider the P in LAMP to be that) has the advantage that there is a huge amount of web applications/sites out there that use it. If you're aim is to be able to modify or contribute to lots of other webapps, I think you should go with PHP. On the other hand PHP is easy to mess up and it is hard to cleanly seperate webdesign and code. PHP has no real application outside of web development that I am aware of (I may be wrong).
Python is a real sweet language with a clean syntax and a lot of (third party) libraries. Python has lots of applications outside of web development.
Google App Engine allows for a clean MVC approach in conjunction with Django (among others). A MVC approach allows to cleanly seperate HTML/CSS/Javascript layout stuff and Python Code.
If you master GAE/Python, it's a small step to go to Django, running on (Linux|Windows)/(Apache|Ningx)/(MySQL|several OtherDB's).
I need to define a runtime environment for my development. The first idea is of course not to reinvent the wheel. I downloaded macports, used easy_install, tried fink. I always had problems. Right now, for example, I am not able to compile scipy because the MacPorts installer wants to download and install gcc43, but this does not compile on Snow Leopard. A bug is open for this issue, but I am basically tied to them for my runtime to be usable.
A technique I learned some time ago, was to write a makefile to download and build the runtime/libs with clearly specified versions of libraries and utilities. This predates the MacPorts/fink/apt approach, but you have much more control on it, although you have to do everything by hand. Of course, this can become a nightmare on its own if the runtime grows, but if you find a problem, you can use patch and fix the issue on the downloaded package, then build it.
I have multiple questions:
What is your technique to prepare a well-defined runtime/library collection for your development?
Does MacPorts/fink/whatever allows me the same flexibility of rehacking if something goes wrong ?
Considering my makefile solution, when my software is finally out for download, what are your suggestions about solving the potential troubles between my development environment and the actual platform on my user's machines ?
Edit: What I don't understand in particular is that other projects don't give me hints. For example, I just downloaded scipy, a complex library with lots of dependencies. Developers must have all the deps setup before working on it. Despite this, there's nothing in the svn that creates this environment.
Edit: Added a bounty to the question. I think this is an important issue and it deserves to get more answers. I will consider best those answers with real world examples with particular attention towards any arisen issues and their solution.
Additional questions to inspire for the Bounty:
Do you perform testing on your environment (to check proper installation, e.g. on an integration machine) ?
How do you include your environment at shipping time ? If it's C, do you statically link it, or ship the dynamic library, tinkering the LD_LIBRARY_PATH before running the executable? What about the same issue for python, perl, and other ?
Do you stick to the runtime, or update it as time passes? Do you download "trunk" packages of your dependency libraries or a fixed version?
How do you deal with situations like: library foo needs python 2.5, but you need to develop in python 2.4 because library bar does not work with python 2.5 ?
We use a CMake script that generates Makefiles that download (mainly through SVN)/configure/build all our dependencies. Why CMake? Multiplatform. This works quite well, and we support invocation of scons/autopain/cmake. As we build on several platforms (Windows, MacOSX, a bunch of Linux variants) we also support different compile flags etc based on the operating system. Typically a library has a default configuration, and if we encounter a system that needs special configuration the configuration is replaced with a specialized configuration. This works quite well. We did not really find any ready solution that would fit our purpose.
That being said, it is a PITA to get it up and running - there's a lot of knobs to turn when you need to support several operating systems. I don't think it will become a maintainance-nightmare as the dependencies are quite fixed (libraries are upgraded regularly, but we rarely introduce new one).
virtualenv is good, but it can't do magic - e.g. if you want use a library that just MUST have Python 2.4 and another one that absolutely NEEDS 2.5 instead, you're out of luck. Nor can virtualenv (or any other tool) help when there's a brand new release of an OS and half the tools &c just don't support it yet, as you mentioned for Snow Leopard: some problems are just impossible to solve (two libraries with absolutely conflicting needs within the same build), others just require patience (until all tools you need are ported to the new OS's release, you just need to stick with the previous OS release).