Don’t sweat it, Rolf. We’re keeping the home fires burning and pulling together as a community to help new players.
HOWEVER, there’s a problem with your new Tumblog. By default your template shows “reblog” links, which means you’re going to get your posts flooded with splog links. I strongly, strongly encourage you to find the part of your template that shows those ‘reblogged by’ links and nuke it, before your readers click on them and get shiny happy malware of their own.
The splog problem at Tumblr is not new—really seems to be the glass jaw of the whole platform.
For your new site, are you considering Scala / Lift? For a team of Java coders, you might really dig it.
wurmonline:
Hiya, this is Rolf, CEO of Code Club AB - the developers of Wurm Online.
There’s been some interesting issues with PHP which we used extensively for wiki, forum, blog and general web pages. Basically our website was hacked into serving malicious web pages so we will stop hosting such services…
In the spring of 2003, I spent a crazy week in San Francisco with Greg Wilkins and Jan Bartel, spearheading the design of their Core Developers Network venture. I remember working all night on their new website with Dain Sundstrom and Jeremy Boynes, and launching the story in the early hours of the morning that a large chunk of the JBoss persistence and web server team were defecting to go their own route. Like the energy from splitting an atom, splitting an idea releases tremendous power. The heat from that dissolution spawned the Geronimo project, and much of the rest is history.
One thing that stands out in my memory is how insanely powerful and sleek Jetty was, and is. On the morning that CDN split off from JBoss, we got “slashed”. The web server was running at Jeremy Boynes’ house near San Francisco, it was running on Jetty, and it never buckled once. It is, in my opinion, the single best web server platform for deploying Java apps that has ever been built. So, it shouldn’t come as too much of a shock that I’m moving back to Jetty, after a long absence (brought on more by the lack of a need to do web development than anything else).
I’m overjoyed to see that Greg and Jan are still at the helm, independent in their development, doing amazing work, and living the dream.
This is essentially where the rubber meets the road for me. I’ve gotten back to the point I was at in Java, with all of the functional power of Scala at my disposal, and a completely redesigned TileForm library. Now it’s time to write the new terrain smoother.
Scala allows you to use the lazy keyword to defer the initialization of member values until they are called. With this technique, you can implement some excellent data structures called streams.
As discussed in Chapter 3.5.1 of Structure and Interpretation of Computer Programs by Abelson, Sussman, and Sussman (a.k.a. The Wizard Book), streams are delayed lists. They let us use sequence manipulations without forcing us to incur the cost of implementing these sequences as lists. Most importantly, we don’t have to initialize every value of a list in order to look at some of the values in the list.
Over the last two days, I’ve applied this technique to a stream-based QuadTree design, allowing me to have a data structure capable of providing access to massive (Terabyte-sized) terrain heightmaps without forcing me to load all of the terrain data into memory at once. Moreover, I can use my streaming QuadTree class to generate the terrain, building as much or as little of it as I need for the sake of demonstrations, and preserving the concept of shared vertices between neighboring (or enclosing) branch and leaf nodes.
This design is modular. Not as much as I’d like, and it needs more refactoring, but it’s modular enough that I could cache the terrain data to disk (or to a network service) after generation, and prune unused nodes from my local copy as I move through the terrain, in order to minimize runtime memory.
While technically possible to do this in Java, it would have been extremely ugly and complex. Once again, I’m really happy to be writing this project in Scala.
Really looking forward to using this!
Java NIO 2.0 (sometimes referred to as NIO.2) provides comprehensive support for the filesystem. Besides enhancements to the way you create, open, read, and write to files, you can now create custom filesystems and file providers in Java as well. One example is the ZIP file provider, which comes with the API and treats an archive file as a filesystem in its own right.
http://drdobbs.com/blogs/java/231600403
Scala 2.9.0 final was released last night: http://www.scala-lang.org/node/9483
The Scala 2.9.0 codebase includes several additions, notably the new Parallel Collections, but it also introduces improvements on many existing features, and contains many bug fixes.
The data structure I was wrestling with last night collapsed into a binary tree as I slept. There’s no good reason to use a structure like that for storage, when a binary tree will do. The lesson to take away from this is twofold: the relationships that are used to generate data need not necessarily linger on the storage of that data, and a binary tree need not be full to be useful.
Inverted B-Tree. What is this data structure? It’s not a polytree because there is more than one path between vertices. It is a DAG, because it’s directed and acyclic. But there’s got to be a name for it.
I’ve now completely refactored my entire graphics pipeline to use PicoContainer for inversion of control, and separated out the engine components into a variety of services which each focus on running and managing different aspects of the entire application.
As you can see, the number of component dependencies is staggering, and the difficulty of wiring these all together might lead me to want to harden my APIs or lock myself into one particular design. Because I’m using PicoContainer to manage not only component construction but also component lifecycle, I don’t have to worry about this concern at all.
Moreover, my top-level Engine can focus its entire attention on coordinating the “main render/update loop”, deciding when to skip render steps in order to help updates keep pace. The StageManager service completely oversees the initialization of the camera, lighting, material and terrain manager services during the startup phase of the component lifecycle. Components without direct dependencies on one another can communicate via message passing, just as the user communicates with keyboard and mouse events via message passing.
As a result of my refactoring, I can work on every component individually, almost with complete freedom from how it is intertwined with other components in the engine. I can unit test components individually, free from entanglement with the rest of the engine. There is a strict separation of concerns that prevents top level elements from manipulating the state of the LWJGL Display, and the “spaghetti code” has been tossed aside in favor of this much more modular, clean, and pluggable “ravioli code” architecture.
Experience tells me that the diagram above is far from perfect, and is continuously in flux. If you want to use it in your project, you’re welcome to it as long as I receive appropriate attribution. If you need help wiring together your PicoContainer, let me know and I might be able to help out!
Here’s a snap of the same geometry from before, rendered with the new engine. New blue-magenta color scale for new architecture shows off the surface slope a little better:
Eschewing method overloading as a matter of principle seems to conform to the general spirit of functional programming, though for the sake of fluent API designs it might still be useful. I’ll have to chew on it some more. Thanks for the detailed post, Chris!
iamchrislewis:
What does a compiled curried method in Scala look like in java? Compile this:
object Concat { def concat(s: String)(ss: String) = s + ss def concat(s: String)(i: Int) = i + s
}
Now inspect the resulting class with javap:
Compiled from "Concat.scala"
public final class Concat extends...
Upgraded to PicoContainer v2.10. Close inspection convinced me that the new lifecycle annotation methods were absolutely crucial, library size be damned.
Here’s an example of how to construct a DefaultPicoContainer instance in Scala, using the version 2.10 API:
val pico : DefaultPicoContainer = new PicoBuilder().
withJavaEE5Lifecycle().
withConstructorInjection().
build().
asInstanceOf[DefaultPicoContainer]
That gives you the actual container. You can now use it to register and instantiate components, like so:
pico.addConfig("width", 800)
pico.addConfig("height", 600)
pico.as(Characteristics.USE_NAMES).addComponent(classOf[Box])
val box = pico.getComponent(classOf[Box])
println(box)
Which yields:
Box(800,600)
The motivation behind using PicoContainer will start to make more sense Real Soon Now™, as I start to add my giant web of dependent game engine subsystems.
Hope this saves you some time getting started with PicoContainer 2.10+ in Scala
Isometric terrain engine written in Scala and LWJGL. First screenshot of 2nd generation engine still lacks many of the terrain processing features of my first cut, and the tiles in this screenshot are positioned manually just so I could get a screenshot. Surface colors are determined by surface slope.
With a little effort and some “clever” workarounds (I don’t like these), I finally got my new vertex buffer object (VBO) code written in Scala! The first tile was a simple cube, but I ran it through some tests to see a few of the other tileforms as well. Instead of drawing the tile edges into the texture itself, I also implemented a wireframe overlay. In addition, I built a mechanism by which I can color the polygons based upon their surface slope, mapping slope to different color schemes.
Next on the list of things to do is redesign the “main loop” to limit it to about 60FPS and release resources when the window is not focused. After that, I need to pull in all of the tileforms and start rebuilding the Terrain Processor system that takes heightmaps and “solves” how to represent them with the various tileforms.
A decade ago, blogging seemed more powerful, more revolutionary, more disruptive… more like the way we wanted the web to be, as opposed to how the corporations wanted it to be.
But like I said, it was hard work. You had to write a lot, every day. And you had to be a good writer with something to say. Or else it would wither on the vine.
In other words, the barriers to entry were high, in terms of both talent and energy required.
So clever, talented people everywhere started inventing tools that made Web 2.0 much easier for ordinary people: Twitter, Facebook, Foursquare etc. That was a good thing.
But I think something was lost in the process. Suddenly it got a lot easier for the bloggers to be lazy.
And so people DID become lazy. In HUGE numbers.
Not that there aren’t any good blogs still out there- of course they are- but in the last five years or so, something magical was lost, or at least, diluted.
I think now is a good time to remind people why we all got into blogging in the first place, all those years ago.
“
| — |
This part resonates, and I’m grateful for the link:
“The content on your blog, however, belongs to you, and you alone. People come to your online home, to hear what you have to say, not to hear what everybody else has to say. This sense of personal sovereignty is important.”
In our own blogs we have the ability to make editorial decisions that affect how seriously we are taken. I never really got into Facebook and Twitter while I was in school, but I kept my blog at the University for years and years.
“Reclaim Blogging”: Why I’m giving up Twitter and Facebook. | gapingvoid (via arielwaldman)
|
