Must see: 3D desktop application
Monday, February 18th, 2008Today I’ve stumbled upon this wonderful 3d desktop application:
WHITEvoid portfolio application
Remembered me of the 3D desktop concept video “Bumptop”:
![]()
Today I’ve stumbled upon this wonderful 3d desktop application:
WHITEvoid portfolio application
Remembered me of the 3D desktop concept video “Bumptop”:
![]()
Only a day after the release of BlazeDS, Nicolas Cannasse (Motion-Twin) has just released haxeVideo:
haxeVideo is an opensource video streaming server entirely written in haXe
Features include :* FLV streaming using RTMP protocol
* Webcam and Microphone recording to FLV file
* Live streaming for web conferencing
* light and fast scalable server
* only 50 KB of server source code : modify whatever you need !
Finally the multiuser/conferencing thing is taking place?
We will ever see affordable (T)RTMP hosting services?
PS: This can be the right answer to those interested in a web-radio solution
This week were released:
AMF3 specification
Action Message Format (AMF) is a compact binary format that is used to
ActionScript object graphs. Once serialized an AMF encoded object graph
to persist and retrieve the public state of an application across sessions or
endpoints to communicate through the exchange of strongly typed data.
And Java-Remoting BlazeDS Beta
BlazeDS is the server-based Java remoting and web messaging technology that enables developers to easily connect to back-end distributed data and push data in real-time to Adobe Flex and Adobe AIR applications for more responsive rich Internet application (RIA) experiences.
Previously available only as part of Adobe LiveCycle Data Services ES, Adobe is announcing its plans to contribute the proven BlazeDS technologies to the community under the LGPL v3. BlazeDS gives the rapidly growing Adobe developer community free access to the powerful remoting and messaging technologies developed by Adobe.
The source code will be available for download in early 2008.
In short: more AMF servers for free, other than RED5
The Doom game in flash:
This uses the original Doom shareware wad file and gets all content from it at runtime.
See it here: Flash Doom game
I've always thought that continuations are the right answer to many if no all the network-programming problems.
A continuation represent the state of execution of a function: all the local variables and the instruction pointer (the last line executed).
(Update: At least: there can be many kind of continuations. Other than the local variables, it's possible to store the state of the entire thread/process/stack)
You can interrupt the execution of a function and resume it later.
This can be useful to create "generators": iterators made simple.
A generator looks like this:
The function next return the next element in the arr array every time is called.
When you call the function you resume the continuation, so the execution will resume from the yield.
If you want to implement an iterator like that without generators you'll have to explicitly unroll the for loop.
The resulting code will be surely less readabe.
Like:
This can get really worse for every non-trivial iterator (eg: tree traversal).
Another nice use of continuations is to generate cooperative threads.
They are different from standard threads because they can't be stopped, they should cooperatively stop.
For example you can do:
The process function return the control to the calling function every time it has to do an asynchronous operation.
Without continuations you'll have to do:
As you can see we have used closures in a Continuation Passing Style:
Every time you have to do an asynchronous operation, you'll have to pass a function (a callback) that will be called when the operation is done.
Without closures the code will look even worst, this is why recently there is a great buzz about closures in the java world.
A continuations-like style of programming (but without continuations) is possible only using threads.
However, threads are the heavier and most problematic way to handle the I/O waitings. (see: 10Kproblem)
You have not only to deal with concurrency problems with read/write variables, but you have to block an entire thread for every I/O operation.
A better way is to use asynchronous events, like in the last two example. But of the two, which one do you prefer?
If your answer is like mine, take a look to:
-> operator the execution can be resumed from that point.Jetty scratched only the surface of what is possible with continuations, while with RIFE it's possible to develop highly concurrent servers using cooperative sessions instead of threads (some >10000 connections instead of 1000). See: Mina Java-NIO library, Perl POE, Mina-Mule.
A server that uses continuations, will allow the simple and linear programming style of blocking-synchronous operations while using non-blocking ones. With a huge increment in performance.
In the client side, the most interesting is NarrativeJs, that use an approach that can be adapted to every language:
it unroll loops and transform all local variables in object variables to generate his quasi-continuations.
became:
The code looks ugly but it is so to preserve line numbers.
With narrativeJs you can do complex animations in a simple, linear way:
or:
Really interesting now that Flash and Ajax are pushing asynchronous operations to the masses.
Will we say goodbye to events, and maybe to threads as we know now?
While I was wondering if using haXe or Java with my server, I've stumbled upon some discussion on Static Typing (Java) vs. Dynamic Typing (Ruby, Php).
In a really interesting blog post (read the comments too) I found this touching phrase:
"Static typing is Communist Bureaucracy".
In short: since we (should) have pervasive testing, Static Typing is only more testing. However, a comment is enlighting:
I'm finding this logic hard to follow. Testing is good, coverage is good. Static typing is, among other things, a way to have the compiler test your code for type issues. Since we like testing, this makes static typing good, right?
But Static Typing not only prevent you to do mistakes, like typos, it allows your IDE to know what you are doing:
DynamicStatic Typing speeds up development because there is physically less to type since ctrl+space and ctrl+2 write the declarations for you.
Its seems obvious to me that Dynamic Typing is worth the catch only for a quick start or for learning.
Since almost all of the dynamically typed languages (like Actionscript, Perl, Php) have migrated to some kind of Static Typing (eg: Type Inference), there should be a reason.
Periodically, a new Dynamically Typed language spawn, attracting junior/tired programmers with the mirage of the simplicity and the less-to-type-ing, riding the hype until his young audience grows and start doing large projects hoping not to call a function with the wrong arguments.
Only then they realize the big truth: Static Typing is just more informations in the source code.
And more information means less wondering-what-object-was or what-was-the-method-name-and-parameters or who-instantiate-this-object, not to mention static analysis.
And hey, they have invented Javadoc-like documentation and Annotations just to add some more information, why remove one of the most important?
Flyer is a open source framwork for symbian phones written in python.
From the site:
Flyer is based on the Flash Lite 2.1 integration with Python for S60 and contains the following features:
- Take photos with device camera from Flash Lite
- Take device screenshots from Flash Lite
- Send files over a bluetooth connection from Flash Lite
- Get the contact entries in the default device database
- Text To Speech
- Sound recording and playback
Moreover: 60% of all donations to Flyer Project will be for Brazilian Children
I've been always fascinated by the capabilities of Flash, especially in making networked applications (and games) that can run everywhere.
Flash is the only tool that can bring to the maximum audience with the minimum effort a full fledged application/media player/real time network client.
Yes, low-latency, bi-directional, real time messaging. (using XmlSocket connections)
But, even if Flash is such amazing stuff, why there isn't so much real time, synchronized, networked Flash applications out there?
After some thoughts, some non-blocking servers and a thesis (jira), I think I've found the answer: the lack of a server.
Yes, there are many, like the promising Red5, the full-fledged (non-free) SmartFox, Oregano, and others, but no one seems to reach a decent level of notoriety and support.
The chosen one seems to be Red5, with SmartFox coming next with his maturity but the lack of streaming, but there is another one that can won the race with a large margin: haXe.
For those who doesn't know, haXe is a compiler/language written by the authors of MTASC (Motion-Twin). His main feature is that it can output running code (or bytecode) for Javascript, Flash 8-9 and the Neko VM, with the same language.
But the most interesting features are coming form the Neko VM: the ability to run as a Apache module and the non-blocking sockets support.
What does it mean?
This mean that with only one language and a common set of libraries it is possible not only to build the client, but even the server side of a web application.
And for server side, I mean all kind of server: 'classic' webserver serving html from a database, Flash Remoting or a massive chat/multiplayer non-blocking server.
Whats the catch? It's a C/C++ stuff and the lack of a large community/hype. However, the capabilities are already exciting.
I hope to find the time to take a better look to haXe. In the meantime, I'll monitor the Java scripting languages support waiting for the ActionScript 3 (Tamarin) ScriptEngine.
Yes, its really wonderful: fully working Flex 2 components in a 3D enviroment (via Gianfranco Torlone)
Richar Leggett wrote on his blog that someone seems to have (re)discovered a new AJAX applications vulnerability and published a paper about that.
However, this type of vulnerability is already known:
when you do a request with Javascript you can only do that to the same domain of your script, but this doesn't apply to
imgandscripttags
So if you browse a malicious site, this can do a request to any site trough your browser (with your cookies and credentials).
In Flash this isn't possible thanks to the crossdomain.xml.
However ever this can lead to vulnerabilities if misconfigured or because of the new loadPolicyFile Flash function.