In our industry a lot of things get picked up because of trend and other hype,
and then generate popularity: a kind of self feeding machine which make someone
use a tech just because other people use this tech, so that must be the right choice, right?.
When your own tech, your baby, is not popular (at all) you can either try very hard
to convince others to migrate to your brand shiny new toy, and if you are heavy enough
it might work (and not work if you’re just a tiny little ant).
Or you can rebel and say “Nope”.
What it is to go rogue?
11. no longer obedient, belonging, or accepted
and hence not controllable or answerable; renegade:
No longer obey what the whole industry is feeding you: “do this, use that and shut up”.
You basically cheat the system (“fuck the system!”) by not following its rules.
Is it crazy? maybe
But the only way to re-invent a system that no longer fit you, to truly think out of the box,
is to go build stuff outside of this system, to do things really differently.
When people tell me “ActionScript 3 is dead because Flash is dead”,
that’s why I say things like “No, ActionScript 3 is now a secret weapon”.
And it’s not only ActionScript 3, it is also the AVM2, the toolchain, the compilers, etc.
Those form a great tech stack base to build uppon.
And that’s why Redtamarin exists in a space where ActionScript 3 was not really expected or even wanted.
The command-line, the server-side, and beyond …
Where no one control us and not forced to answer to anybody.
Free to build and create.
It is a “secret” because nobody want it or use it, it’s not “à la mode”;
and it is a “weapon” because you can still build great stuff with it,
and do so, I believe, faster and better (also stronger and harder).
From the very beginning it has been about that: building software with ActionScript 3.
To me the perfect hybrid language which can go as “dirty” as you need it to be,
and at the same time go as “structured” and “organised” as wanted by those … more complicated things.
So during 2016, you didn’t see a lot of things being created with Redtamarin,
I know I know, you see no activity on an open source project, and you are already jumping to conclusion:
“this project must be dead or abandoned”.
Nope, that is called “stealthy mode”
The last 11 months of “inactivity” is just the public stuff you can see on Github,
Redtamarin is developed via subversion on private servers which then are mirrored later.
There have been tons of commits and changes, you just don’t see them yet.
It’s not ready yet, I work on the
trunk, I publish when the
trunk is stable.
But those changes are not that important (even if there are massive and coming in the 0.4.2 release),
what matters is by using Redtamarin on a daily basis I kept creating tools and other utilities,
I kept automating stuff (the only way to survive when you are a “one man shop”), so here few examples:
When working on building some complex REST API
I needed a way to test the input and output of those API
bashwas OK for a start but failed at more complex scenarios
those API are connected to different IoT and other sensor devices
so I needed a way to emulate those and for that I built “virtual sensors”
as command-line tools built with Redtamarin so I could emulate different
protocols and behaviours for “presence detected”, “lights are on/off”, etc.
When working on servers I needed to automate many things
like the listing/creation/setup/backup/etc. of http/ftp/svn/mail/database/etc.
again I could have used
bashbut I needed to deal with many entities and hierarchies
so for that I used as3shebang to manage many domain name, many virtual hosts,
many ftp user accounts, many svn account, etc. for many organisations and customers
all those AS3 shell scripts have been a real time saver
and “cherry on the cake” I can now easily migrate them to proper command-line exe
inbetween the servers automation and command-line tools
I needed “services that monitor and react on stuff”
so I built daemons for Linux that read logs, find specific stuff with regexp
and act uppon it by telling the system to open/close/update other stuff
I built all that with an internal beta of redtamarin 0.4.2 for the daemon part
and another command-line tool to manage it via sockets,
pretty efficient, I like it and I can deploy/update it in seconds
Now in 2017, the goal is to publish some of those tools in a more professional manner,
because “wow that’s really useful” or “hey it does save a lot of time to do it like that”
and yeah “looky here, it’s build with redtamarin and it is easy to use” .
Which is mainly why I operated in the shadows, I know the stuff is good
but I did not want to come up and present half baked shit
“oh look you can make a socket connection!” … no, that’s too easy.
What I want is to show you how to build a chat server,
or how to build a custom interactive shell like what’s Github is doing,
and tell you that both take only 20 lines or so of ActionScript 3.
That’s a bit harder to pull off but much more interesting imho.
Build and create useful tools that do useful stuff and make all that easy.
I don’t get too much into the details of which tools for what use
but 2017 should be an interesting year for Redtamarin tooling ;).
Redtamarin is a complex beast to work with, it’s not only the C/C++ parts,
it is also the building/writing/testing of those parts when those parts are all
moving at the same time and so on different operating systems.
At first I was using a lot of Virtual Machines but those require a lot of RAM,
so when you’re stuck with 16GB of RAM you soon reach the limits of what you can do.
Then I moved to external hardware to provide “little island” of testing with
their own ressources (CPU and 8GB RAM), which is not that bad but also limited
in some ways.
So if your automation does not provide all the power and speed you need,
here my advice: keep automating, keep making your workflow better.
In order to do that I needed more power to be able to do many stuff in parallels,
and I also needed much more screen space specifically to be able to switch
between many different projects with long not too easy to edit source codes.
My answer to that for now is a beefy hackintosh with 64GB RAM and 3 monitors.
Yep, it is an investment, but it was so much worth it, I can now edit a dozen
code projects on virtual spaces (that’s 3x 12 = 36 screens) using less than 32GB of RAM
and at the same time span many VM with the other 32GB of RAM, while I still
remote run/launch/compile stuff on the external hardware (which now include a mac mini with 16GB of RAM).
With that I can now write and compile C/C++ in less than 2 minutes iterations,
I can test and experiment more and do it faster.
The best part is I can switch between projects (work related or open source related)
in a split second with not too much damage or latency in the “coding flow”.
I have plans, I organise stuff, but sometimes you need to go with your instinct,
and being able to jump into a project just to test an idea that came up few minutes earlier
is priceless to say the least.
For example with the 0.4.2 release of Redtamarin I had planed an API for sockets,
which is basically “programming stuff for input/output over the wire”,
but then I realised I could do also something much basic and usefull as
“programming stuff for input/output, period” and that how the streams API were added.
All that new hardware goodness for what?
For the big complicated stuff to come into Redtamarin.
I now have the need to work on branches, and that means being able to add and explore
big span of C/C++/AS3 code on “experimental” implementations, in parallel of what
I’m already doing with Redtamarin.
Using subversion, working on the
trunk for the main implementation, and working
on branches for other implementations, and merging if all goes well, is a classic
not too hard thing to do.
But when you do it in parallel and it’s based on C/C++, believe me you need that
kind of hardware power, it’s not overkill, far from it.
This whole new workflow should now allow me to provide much more regular public updates,
because I’m simply not stuck on experimenting big stuff in the
It should also highly influence the amount of tools and other utilities I can put
“out there” for public consumption.
The Discovery of the Obvious
An open source project if made of ups and downs, and sometimes among all that mess
you get lucky without really realising it right away.
I remember, it really started with v0.2.5, it made sense to have this
to have the C headers like
stdlib.h as package names eg.
but at that time I was completely oblvious on how much this would influence
the design of the API.
It shaped up more with v0.3, then v0.4 it’s really where I saw how much important
it was to have this low-level C API.
I was following a sound plan: write as less as possible of native C/C++,
because I was not that good with it in the first place, because it was so slow
and error prone to implement, because once you got that tiny bit of native functionality
you can really glue “all the rest” with ActionScript 3.
And that was falling into place with the 3 layers of API: C API, Redtamarin Native API,
and AVMGlue API (that’s Flash/AIR API implementation).
So yeah I had a “big picture” but it was still a bit blurry on some places,
now it’s perfeclty clear and fluid.
The C API is the most important native API of Redtamarin, it is the solid flat ground
on which you build everything else.
But it is complicated, not only the native implementations, but also using it in AS3.
Because to really use all its powerfull features you need to know both C and AS3,
which is not something that everyone want to mess with.
That said, this C API is here to stay and to get better and better with time,
honestly it is already quite good, but I still have ways where I know I can improve it.
About release 0.4.2 in relation to the C API, here what happen when you decide
to use a powerful API to really get into implementing the “hard” stuff.
Bare with me, imagine for a minute you are developing software in C++,
you would rely on this C functionalities to implement your classes and
build the structures and other logics you need.
The problem is you have to know and compile C/C++.
Those are great tools but you can easily burn yourself with them.
Now, let’s do it the Redtamarin way, you have the C API and the whole
ActionScritp 3 language to build your software.
Granted, using the C API “as is” is hard, but once you got few utilities
as AS3 classes, it gets easier and easier, and you can build uppon those,
and grow your software more and more.
And with the same logic of the Flash or AIR API, it is cross-platform “by default”,
once you know how to use a class to work with sockets, you can reuse it anywhere
without really thinking twice about it.
proto042 is about: it shows how you can use the Redtamarin C API
to build such utilitarian API, such as
StreamClient to work with TCP streams,
DatagramClient to work with UDP datagrams, etc.
You will notice that the Redtamarin
shell.network.StreamClient is very close
to something you already know
flash.net.Socket, and same for the other one
shell.network.DatagramClient is pretty similar to
Sure you will need a bit of documentation and other examples to get going,
but it is much more easy to grab than to do it all with the C API.
Some people will just use those API “as is” and build more stuff with it (I hope),
some others will go into the implementations details and have the same revelation I had
“Holly shit, you can do all that with the C API ?!?”, yes you can :p.
So those new set of API are not a perfect and flawless implementation, if used enough
I’m pretty sure some bugs will get discovered (and fixed) but they are here for that:
make things easier.
Once you got something like a
FileSystem class and a
implementing your own
SimpleHTTPServer (like Python) is one easy step away.
On my side I struggled a lot to get those API implementations “right”,
mainly because I wanted those API to be embedded by default in the runtime
and not be an external library that you have to load, so yeah it made things
a bit more complicated to develop and to test, but so much worth it.
It’s not a huge API, it’s just streams and sockets but it should allow
to build much advanced and better things.
The Next Stuff to Come
Just because of release 0.4.2 (which embed
proto042, everyone is following?)
all the default tools from
as3shebang and other libraries
httplib etc… will be updated and improved.
The next focus on the C API will be about processes, how to control them, kill them,
read their input and output at the same time, etc.
You will see also implementations for users management: creating user, creating groups,
adding user to a group, changing a user password etc. and access to native logs API
like syslog and other Windows logging.
And from those you will also get the “nice API” classes,
UserManagement.createUser( login, password, other, options ),
that’s the next proto.
The pace of Redtamarin releases should increase, for
0.4.2 I kept the tools
redbean unchanged, but the next versions of those tools will grow in
functionalities and you may have a new Redtamarin release
0.4.3 just to do that:
updates the tools.
On top of that you will get some “hello world” projects dedicated to show how
you automate and build stuff, for example: how to build an interactive shell,
how to build a daemon for Linux, how to build a daemon for macOS, etc.
And some published tutorials, that will focus on building simple tools like
how to build a TCP/UDP port scanner, how to build an HTTP server, etc.
which some more details on the why it is done this way with Redtamarin.
Not sure of the format yet, it could just be the classic blog post or even
published within a book or something.
That’s about the plan for this 2017 roadmap.