-
Notifications
You must be signed in to change notification settings - Fork 23
2015 12 23_2015_year_in_review
So far, stop updating the C/C++ sources code and building things with it (redtamarin) was not a bad idea.
It worked well for some parts, brought a lot of "lesson learned" for some other parts but ultimately shed some lights on what need to be done.
Let's clarify a couple of things before going into the details :)
- redtamarin is an open source project, not a company, not a startup
- redtamarin is mainly a solo act eg. there is one guy (me) working on it
- still redtamarin is more than just a toy project done over a week-end
- yes there is a struggle with the amount of time I can personally put into it
- no, nobody will pay or sponsor something like redtamarin
About 2 years ago, Redtamarin just got updated to v0.4 and I was ready to use it.
Except, at the time, on a server side project I got confronted to the arguments
Your Redtamarin does not seem ready
we' re not gonna use it, we gonna use PHP
which basically translate "we don't trust the technology", and yeah I must admit I chickened out, I did not slam my little fist on the table and did not fight for Redtamarin and did the development with PHP.
But once this project was done, I got another reaction
You don't want to use Redtamarin, fine
fuck you, I gonna use Redtamarin on my own projects
I don't blame anyone, but it's basically how it is, you can list the features, you can explain the potential of the tech, go into details about the pros the cons etc. as long as the technology itself is not used for real projects nobody gonna take this tech seriously.
The proof that the technology is worth using is to simply use it.
Based on that, I decided to integrate and use Redtamarin on whatever I was working with.
Like any tools or any tech, you need to have a way of doing things.
This started with a Redtamarin SDK, a simple one
- where/how to organise the different runtimes (redshell)
- how to compile programs
- how to organise libraries
- and tons of little details
In the SDK, the best part imho is the tooling with redbean, once you have everything in place, you can simply reuse the Flash Builder IDE, write a lot of code, an simply use redbean to compile.
The bad part is to have first to put everything in place to obtain this
redtamarin
├── 0.4.1T174
├── bin
│ ├── as3hash
│ ├── as3hash-macintosh
│ ├── redbean
│ ├── redbean-macintosh
│ ├── redshell
│ ├── redshell_d
│ └── redshell_dd
├── doc
│ └── ...
├── lib
│ ├── asc.jar
│ └── asc2.jar
├── lib-abc
│ └── redtamarin.abc
├── lib-swc
│ ├── redbean.swc
│ └── redtamarin.swc
├── runtimes
│ ├── avmshell
│ └── redshell
└── tools-abc
└── redbeanthe runtimes part being the worst
redtamarin/runtimes/
├── avmshell
│ └── macintosh
│ └── 32
│ ├── avmshell-debug
│ ├── avmshell-debug-debugger
│ └── avmshell-release
└── redshell
├── linux
│ ├── 0.4.1T174
│ ├── 32
│ │ ├── redshell
│ │ ├── redshell_d
│ │ └── redshell_dd
│ └── 64
│ ├── redshell
│ ├── redshell_d
│ └── redshell_dd
├── macintosh
│ ├── 0.4.1T174
│ ├── 32
│ │ ├── redshell
│ │ ├── redshell_d
│ │ ├── redshell_dd
│ │ └── test.as
│ └── 64
│ ├── redshell
│ ├── redshell_d
│ ├── redshell_dd
│ └── test.as
└── windows
├── 0.4.1T174
├── 32
│ ├── redshell.exe
│ ├── redshell_d.exe
│ └── redshell_dd.exe
└── 64
├── redshell.exe
├── redshell_d.exe
└── redshell_dd.exeBut even if complicated, it allowed me to move forward using the tools, and yes lesson learned the SDK "as is" sucks and it gonna change.
So far what works well is to have an executable associated with a shell script, for example
redtamarin
│
├── bin
├── as3hash <-- bash script
├── as3hash-macintosh <-- executable, redshell merged with as3hash.abcand then you do symlink
/usr/bin/as3hash -> /usr/share/redtamarin/bin/as3hashfrom that point you can use the as3hash tool anywhere on your system.
It's OK'ish but not good enough and this is why the SDK gonna change, I will get into those details later.
Other use I made with Redtamarin is replacing Bash scripts with AS3 shell scripts.
So, ActionScript 3.0 shell scripts, yep it started as a hack but was an eye opener.
You can check out as3shebang if you want but here I will talk about how and why I use it.
Here the best features of as3shebang
- straightforward install
sudo dpkg -i as3shebang_0.9-1_amd64.deb - reusable, editable scripts
eg. it is just text - it can reuse ABC libraries
eg. precompiled AS3 code - instant executable-like
eg.$ chmod +x yourscript
Simply put, you can go very far from a
#!/usr/bin/as3shebang --
trace( "hello world" );At first you can think "oh he's using AS3 for the sake of using AS3", but not really, I didn't force myself to write shell scripts in AS3, on a daily basis as a sysadmin on different Linux servers this as3shebang really improved a lot my workflow.
Let's be clear, I wrote big and long Bash shell scripts for years, like for example to do backups, you would want to tar/gz a filepath, dump a MySQL database, zip the files in a nicely named zip "2015-12-25_website.zip" and save it to a local backup and a remote backup etc.
I also wrote shell scripts in Perl, PHP, Python, Ruby, etc. because when your script get more and more complex Bash is really painful and you want a more structured programming language, ActionScript 3 can work too.
And when you compare writing shell scripts in AS3 vs PHP, I found out that there are more pros than cons.
So yeah it started like that, if I needed anything more complex than a dozen lines of Bash, I would go directly with AS3 used with as3shebang, and if I needed anything bigger than few hundred lines of AS3 shell scripts I would isolate some code in a reusable library.
Very dumb example "oh I want to display stuff in colors" I would just dynamically load the ansilib.abc
and it would work like that:
#!/usr/bin/as3shebang --
import shell.*;
// load dynamically the ABC library
var ansilib:* = Domain.currentDomain.load( "/usr/lib/redtamarin/ansilib.abc" );
//trace( ansilib + " loaded" );
// from that point I can import from the lib
import encoding.ansi.*;
// do stuff in colorsnotice the path "/usr/lib/redtamarin/", yep that's where I keep all my libraries like you would use "/usr/lib/php5/", "/usr/lib/python3/", etc.
so what have changed really
- when I admin a server
the 1st thing I install is as3shebang - I can transfer/reuse/edit AS3 shell scripts
via FTP, SSH, copy/paste in nano etc.
sshfs and/or rsub - I'm 10x times more productive on a server
- so far as3shebang is used as my main admin "tool"
on 20 servers or so
It's a very good feel not only because it works but also because of tons of other little things
- you can edit a shell script in Flash Builder
much faster to use syntax completion - the clib in redtamarin give me the power of C in AS3
- native support for XML, JSON, ByteArray, Sockets, etc.
- error stack traces
- testing/mocking
- libs such as ansilib, clilib, prettyprintlib, etc.
- the result is extremely professional
as good as an exe command line tool
And I applied the same thing with AS3 server side, see the next part.
One of the big challenge of using AS3 was also using it on the server side to replace such thing like PHP, Python, Ruby, etc.
I already made a prototype with the web site www.burrrn.com and from that launched something else with www.as3lang.org.
And yeah here you can accuse me of "using AS3 for the sake of using AS3" as I could have used PHP to build the very same things.
But here I would argue "being stubborn paid off".
Server side Languages like PHP, Python or even Perl have years if not decades of usage on top of AS3, so there are a lot of to catch up with, but now taking a few steps back, it's not a stupid thing or desperate thing to do.
I can see now numerous clear advantages of using AS3 as a server side language beside just using AS3 the language.
At my core I'm a developper, I started to write code with Perl back in the 90's, moved to ASP classic with vbscript then jscript, and later PHP, and I kept up to date from there with different languages, frameworks etc.
So I'm not here to say that AS3 is better than PHP or anything else as I would generally argue than one language is not really better than any other language, but I could argue that some workflow are better than others.
Also, since the 90s to now 2015, the way developers use server side languages have evolved a lot.
What are the problems
- most people will tell you that "CGI is obsolete"
no they are wrong but true CGI is slow in the sense that it does not scale well
as you need to execute a process for each server requests - those CGI problems can all be solved with FastCGI
if you digg enough in things like HHVM
you realise that in fact they do use FastCGI to solve the same kind of problems - if you search enough into Node.js
the principle is very close to FastCGI but done differently - Redtamarin is not just using the ActionScript 3 language
it is also using the AVM2 (ActionScript Virtual Machine) - AVM2+AS3 is very good combo of tech
at least as good as V8+JS which Node.js use - what people are really after is
"how to build application servers"
that are fast and can scale- Java + Tomcat can do that
- PHP + HHVM + FastCGI can do that
- Node.js (V8+JS+loop) can do that
- guess what? AM2+AS3 can do that too
- use our own HTTP server main loop (like Java/Node.js does)
- reuse a protocol like FastCGI (like HHVM does)
- we can definitively move forward just using CGI
everything will become automatically compatible with FastCGI
once FastCGI is implemented
Here a couple of things I discovered using AS3 as a server language under CGI
- CGI is the most compatible protocol
to test on different operating systems
and to test with different HTTP servers (Apache, IIS, etc.) - Compiling all your source code into ABC bytecode
is like building a client side app
for online you build a SWF file that you embed in HTML
for app you build an AIR app which is basically a SWF file underneath - the big difference is that ABC bytecode execute server side
- if you want non-compiled code you can reuse shell scripts
create a pagetest.as3
make it a shell script$ chmod +x test.as3add this to an#!/usr/bin/as3shebang -- trace( "Content-Type: text/plain; charset=utf-8" ); trace( "" ); trace( "hello world" );
.htaccessrun itOptions +ExecCGI AddHandler cgi-script .as3
http://www.domain.com/test.as3
it will run - you definitively don't want "pages"
you want a server side application that deal with the "pages" - let's take from Ruby On Rail
and use the same "route" approach to solve this problem - when you have an app (bytecode)
that can deal with multiple routes (eg. "pages")
you can do anything you want
So yeah, I like the fact you don't need to compile PHP and you can hack around few pages and edit the source code and just refresh the page to see the results, that's a nice learning curve.
But that way of doing, when you are using big frameworks like Symphony or big CMS like TYPO3 end up being a freaking hell, I mean really? few 100MBs of PHP pages with includes/requires all over the place, that you load for each requests? hell no!
And in fact, if I was to build a server side application based on PHP, I would use something like Slim PHP (that deals with the "routes") and do a nice OO structure with maybe some external PHP libs like fpdf, phpmailer etc.
That's basically my approach for the AS3 server side
- keep it application oriented
not like you would do with Java Enterprise
not with a huge framework like PHP Symphony
but simple and lightweight
you produce one app, not a multitude of pages - produce 1 binary (eg. the bytecode)
for now it is an ABC file that include everything (even the code not used) later it would be a SWF that include only the code that is used - the same binary
can work with CGI, FastCGI, custom HTTP server
can work locally and remotely - the data is not part of the app
databases (for now CouchDB), config files, XML, JSON, etc. - the rendering process of a "page"
is just a custom HTTP response
you can switch from plain text to HTML
as well as switch from X HTML to Y HTML templates
It works pretty well, I basically write server side code in Flash Builder with nice syntax completion, I can make quick local tests without having to update the server, and when I need to update the server I just need to push an updated binary (the bytecode).
It is extremely similar to write a client app in AIR, so yeah you do compile it, but that one generated bytecode is easy to version, easy to deploy, easy to backup etc.
It works for regular HTML "pages", as well as custom pages for when you want to do some REST services, something I appreciate a lot as I can have a clear view how every routes the app can handle.
It can be mixed with static files, and it can also be mixed with shell scripts pages here a small example
htdocs
|_ index.abc -> the app will deal with routes like /about /something etc.
|_ static
| |_ logo.png -> apache will serve anything under /static/filepath
|
|_ status -> shell script page that serve /statusstatus look like
#!/usr/bin/as3shebang --
trace( "Content-Type: text/html; charset=utf-8" );
trace( "" );
/*
custom stuff generated from some command line tools
*/Sure a lot of libraries are missing, I can not use MySQL or SQLite, or generate PDF and other stuff, but this will come with time.
Only bad thing is for as3lang.org I guess I promised too much too soon, nothing impossible to solve but while I was working on it I got caught by other works so the development got postponed.
But all that are for good reasons :).
The things that got me busy since last October or so is basically a new project focused around Redtamarin.
Building with Redtamarin, using Redtamarin on a daily basis, AS3 shell scripts, some server pages etc. is all nice and work well on the principle "eat your own dog food" but still had this crucial flaw: I don't make a living from it.
That's a real problem in the sense that till now I was using my free time to work on Redtamarin, even if I was using AS3 shell scripts to do sysadmin work, using some tools integrated in my workflow, the whole "business" does not depends on Redtamarin.
One way to solve this problem is to have paid time to work on Redtamarin, I will never find a company that hire me to work with Redtamarin so I need to create this job from scratch.
This is also a double edged sword, if Redtamarin fails me it will impact the business.
But I think the risk is worth it, I for one trust Redtamarin can do the job and I have also seen how just as3shebang improved my workflow for the last year, so I planed a specific line of work where I do need something like Redtamarin to help me do the job.
Starting in 2016 (around february), I will be providing dedicated server hosting and sysadmin services.
Redtamarin will be used to prep/setup/install/manage Linux servers, for example: let's update 100s of server with that new version of something, a bit like you would do with Chef or Ansible.
The other use of Redtamarin will be to provide admin panels where for example a user with no sysadmin knowledge will be able to create new FTP users, change their passwords, and other basic tasks like that.
voila, 2016 will be a full time Redtamarin year :).