I just started loading my streaming TNG episode, intending to watch it immediately, but then I thought I could better let it load for a while, while I gave private static some more thought. (Yes, last time I wrote about star trek I was at the first episode of DS9 and now I am halfway TNG. I tend to go through series at a reasonable pace - there was some time of not watching any Start Trek between watching DS9 and TNG.) Well... let's just say Javascript is powerful, really believe me! Now!
Oh man, the solution is so simple yet so good. All I did was declare an anonymous function that encapsulates both our class definition and our static functions and call that function right away. This requires a little change in syntax to make the class available outside that function, but that truly is a piece of cake. Once that is done, our private static variables can live in this new class.
It truly is amazing how powerful javascript is.
Sunday, October 25, 2009
Jasoop Redesign
I have been typing for the documentation of Jasoop - which is what I called my style of javascript oop I talked about two days ago (technically yesterday, but not in reality).
And now I have already decided that I am going to change it all already. Here's the story.
I had thought of a way to create static functions, however, I had not realized that it would fail if the function was later redefined. Of course, this does not really matter for functions, but it did mean that I could not use the same technique for static variables. So I was once again posed the same question: how to design static in Jasoop.
I did come up with an answer: if each static property would be an object with one property (say static) I could write some code to make sure these variables were static, while keeping the syntax rather clean. Alright you would now have to type "varName.static", but that's hardly a loss. Then it hit me, if I reversed the syntax there, the code to make the variable static would be (ironically) static, rather than depend on the static variables - and I would get a nicer syntax to boot. Say it yourself: "static.varName". Isn't that much better?
My next issue was deciding whether to use the same syntax for functions or not (I mauled this all over in my head while cooking my dinner). My first impulse was not to do so, because I thought not having to write that static there would just feel much more natural. In the end, the uniformity for variables and functions did win - partly due to an argument that is really nonsense, but I only realize that while writing this. Oh, and don't worry, currently I have more than enough reason to keep it the way it is. The door was now ajar.
Next I thought of a way to create protected variables. I did think of a way (giving the class a return value if it was not called with the new operator), but that did leave me with two challenges: how to differentiate them from private variables and how to pass them through a single return value. Both questions had a single answer, I could simply use the syntax I just made up for static variables. "protected.varName" makes sense, right? Suddenly the door was swinging wide open.
And then opportunity presented itself. I could get rid of all those differences between the variables with different access levels, while getting rid of that ugly _this variable I had to introduce. Man, it cleaned up the syntax, it sure did. I was standing in front of an open door and the other side was much more beautiful than this one - needless to say I went through.
So now, inside the class we have "public.publicVar", "protected.protectedVar", "private.privateVar" and "static.staticVar". One little thing to note is that all static variables are public, but as of yet I do not see any way I can change that (unless static functions are defined outside the "class definition" they can only be accessed once the first object of the class has been created, and outside the class definition you cannot reach protected or private variables).
From the outside you can reach "object.static.varName" and public variables in some way, but I am not sure yet whether that will be "object.varName" or "object.public.varName". Perhaps it will make itself clear once I have found a way to make static variables with different access levels.
Anyway, Jasoop is coming to life and I am pretty sure the result will be nice and it will probably even include features not yet seen in javascript (protected variables, to name one thing).
And now I have already decided that I am going to change it all already. Here's the story.
I had thought of a way to create static functions, however, I had not realized that it would fail if the function was later redefined. Of course, this does not really matter for functions, but it did mean that I could not use the same technique for static variables. So I was once again posed the same question: how to design static in Jasoop.
I did come up with an answer: if each static property would be an object with one property (say static) I could write some code to make sure these variables were static, while keeping the syntax rather clean. Alright you would now have to type "varName.static", but that's hardly a loss. Then it hit me, if I reversed the syntax there, the code to make the variable static would be (ironically) static, rather than depend on the static variables - and I would get a nicer syntax to boot. Say it yourself: "static.varName". Isn't that much better?
My next issue was deciding whether to use the same syntax for functions or not (I mauled this all over in my head while cooking my dinner). My first impulse was not to do so, because I thought not having to write that static there would just feel much more natural. In the end, the uniformity for variables and functions did win - partly due to an argument that is really nonsense, but I only realize that while writing this. Oh, and don't worry, currently I have more than enough reason to keep it the way it is. The door was now ajar.
Next I thought of a way to create protected variables. I did think of a way (giving the class a return value if it was not called with the new operator), but that did leave me with two challenges: how to differentiate them from private variables and how to pass them through a single return value. Both questions had a single answer, I could simply use the syntax I just made up for static variables. "protected.varName" makes sense, right? Suddenly the door was swinging wide open.
And then opportunity presented itself. I could get rid of all those differences between the variables with different access levels, while getting rid of that ugly _this variable I had to introduce. Man, it cleaned up the syntax, it sure did. I was standing in front of an open door and the other side was much more beautiful than this one - needless to say I went through.
So now, inside the class we have "public.publicVar", "protected.protectedVar", "private.privateVar" and "static.staticVar". One little thing to note is that all static variables are public, but as of yet I do not see any way I can change that (unless static functions are defined outside the "class definition" they can only be accessed once the first object of the class has been created, and outside the class definition you cannot reach protected or private variables).
From the outside you can reach "object.static.varName" and public variables in some way, but I am not sure yet whether that will be "object.varName" or "object.public.varName". Perhaps it will make itself clear once I have found a way to make static variables with different access levels.
Anyway, Jasoop is coming to life and I am pretty sure the result will be nice and it will probably even include features not yet seen in javascript (protected variables, to name one thing).
Saturday, October 24, 2009
Javascript OOP
Go ahead, try googling "javascript oop". Or you you can just take it from me: you'll get a thousand ways to do object oriented programming in javascript.
Don't get me wrong, javascript a very powerful language. And I really mean very powerful. Most people working with it, though do not know its full power. For example, javascript lets you write curried functions - the syntax will be strange, but you will have curried functions, meaning you can actually go and use javascript as a functional programming language (oh, it will look horrible, but the point is that you can).
As I said, there are a lot of ways to do object oriented programming in javascript, and it appears there are few people who use the exact same way. There is a way that s default in javascript, but it has its limitations, which - as powerful as javascript is - you can work around. I picked up a style in this that turns out not too be all that common, used some more common elements in it and even added a little that is completely my own.
So that is why I decided that I am going to document this stye of object oriented programming and all its powers. For example, the model supports private data and functions, has its own (but really solid) way to define inheritance. I will document not only how to do something, but also why it is done in this way and not in some other way.
First and foremost, this will be a reference for me, so I can write consistent OOP code in javascript and so I can use powerful features - such as static functions - without first having to dig through old work to see how I did that again. However, I will make it available for others to use, as it can be a useful guide how to achieve some standard OOP features in javascript - and one might even consider using the style as a whole in order to be consistent in one's own work while having a number of powerful features at your disposal.
I do not know how I will exactly provide this documentation, right now I am just typing out the text that documents it. However, I will get back to you on that point.
Don't get me wrong, javascript a very powerful language. And I really mean very powerful. Most people working with it, though do not know its full power. For example, javascript lets you write curried functions - the syntax will be strange, but you will have curried functions, meaning you can actually go and use javascript as a functional programming language (oh, it will look horrible, but the point is that you can).
As I said, there are a lot of ways to do object oriented programming in javascript, and it appears there are few people who use the exact same way. There is a way that s default in javascript, but it has its limitations, which - as powerful as javascript is - you can work around. I picked up a style in this that turns out not too be all that common, used some more common elements in it and even added a little that is completely my own.
So that is why I decided that I am going to document this stye of object oriented programming and all its powers. For example, the model supports private data and functions, has its own (but really solid) way to define inheritance. I will document not only how to do something, but also why it is done in this way and not in some other way.
First and foremost, this will be a reference for me, so I can write consistent OOP code in javascript and so I can use powerful features - such as static functions - without first having to dig through old work to see how I did that again. However, I will make it available for others to use, as it can be a useful guide how to achieve some standard OOP features in javascript - and one might even consider using the style as a whole in order to be consistent in one's own work while having a number of powerful features at your disposal.
I do not know how I will exactly provide this documentation, right now I am just typing out the text that documents it. However, I will get back to you on that point.
Friday, August 21, 2009
Gimmick or Driving Force
I have been away for "Fantasieland" (which, you guessed it, would translate to fantasy land), which is the smaller brother of "Kinderdorp" the past three days, but I'll talk about that later. Right now I wanted to talk about something even more recent. I just watched the first episode of Star Trek: Deep Space Nine.
I intend to watch all Star Trek episodes some time. As a kid I watched a number of stray episodes, but never watched it all. I started by watching Voyager, as I had seen the most episodes of it. Next I decided for DS9 because it plays in the same time.
The first thing that my eye fell on in the series opener is how the anomaly in the episode is a gimmick rather than the main drive of the episode. Here, the wormhole is an important plot point for the series, but the episode is not about it. The timeless alien (which is not executed flawlessly* by the way) is used as little more than a gimmick. In Voyager if such a strange thing showed up it would always be the focus of the episode. I like this way better (or at least, it not always being the focal point of the episode). I have yet to watch the rest of the show, so I'll have to see if this continues to be this way. Anyway, that makes one point for DS9 (of shich I have only seen the series opener) against only a handful for Voyager (all of which I have seen).
* There are two problems with the alien. First, it fears to be destroyed. Second, it agrees to let ships through from now on. Neither of these fit the model of an alien who has trouble understanding beings living in linear time. I don't know if these problems could have been avoided, though.
I intend to watch all Star Trek episodes some time. As a kid I watched a number of stray episodes, but never watched it all. I started by watching Voyager, as I had seen the most episodes of it. Next I decided for DS9 because it plays in the same time.
The first thing that my eye fell on in the series opener is how the anomaly in the episode is a gimmick rather than the main drive of the episode. Here, the wormhole is an important plot point for the series, but the episode is not about it. The timeless alien (which is not executed flawlessly* by the way) is used as little more than a gimmick. In Voyager if such a strange thing showed up it would always be the focus of the episode. I like this way better (or at least, it not always being the focal point of the episode). I have yet to watch the rest of the show, so I'll have to see if this continues to be this way. Anyway, that makes one point for DS9 (of shich I have only seen the series opener) against only a handful for Voyager (all of which I have seen).
* There are two problems with the alien. First, it fears to be destroyed. Second, it agrees to let ships through from now on. Neither of these fit the model of an alien who has trouble understanding beings living in linear time. I don't know if these problems could have been avoided, though.
Sunday, August 16, 2009
Kinderdorp 2009
For the past week, I have been working (on voluntary basis) at Kinderdorp (translated: Children's Village). The main activity of building huts. A good amount of space and wood is reserved for this. However, there's a lot more to it. The tents also take a good amount of the space. There's a podium, a 'crea' tent, the KD bar, a dancing tent, a face paint tent, and a lot more. I was in the crea tent, where the childeren could play with clay, saw nice shapes in thin wooden plancks, paint or make just about anything with all the materials lying around.
We had a reasonable year with over 1600 kids most of the days. And believe me, with no more than 143 volunteers (and quite a few of them only part-timers) that meant some hard working. And man, you're glad when, at 4 o'clock, the children leave. Anyway, some 1700 people had a good five days and I was one of them.
We had a reasonable year with over 1600 kids most of the days. And believe me, with no more than 143 volunteers (and quite a few of them only part-timers) that meant some hard working. And man, you're glad when, at 4 o'clock, the children leave. Anyway, some 1700 people had a good five days and I was one of them.
Monday, July 27, 2009
GoodLooking Demo
Two days ago (technically yesterday early morning, but the two sort of blended together as I didn't sleep in a (successful) attempt to get my sleeping pattern back to something a bit more normal) I wrote about GoodLooking INT02. Today I decided to take a minute and write a demo.
Previously I provided links to the template and the live example. Now, instead, I provide a link to the demo. From there you can have a look at the running example, force it to do a reload and from there you can see the source of the template, of the sample application, of the code connecting the two and of the compiled template.
All of these are actually viewable without looking at the source thanks to two pre-tags around them and an htmlentities that was executed on them. It is important to note that even thought the compiled template is viewable this was, it was not made to be good to the eye - it is very ugly, generated php. Here's the link.
Previously I provided links to the template and the live example. Now, instead, I provide a link to the demo. From there you can have a look at the running example, force it to do a reload and from there you can see the source of the template, of the sample application, of the code connecting the two and of the compiled template.
All of these are actually viewable without looking at the source thanks to two pre-tags around them and an htmlentities that was executed on them. It is important to note that even thought the compiled template is viewable this was, it was not made to be good to the eye - it is very ugly, generated php. Here's the link.
Sunday, July 26, 2009
GoodLooking INT02
I did some work on GoodLooking, my templating engine, again. And I finished a number of goals I had set for myself, and as such I finished the next version, INT02. Note that INT02 is not a release yet, not even an alpha release - INT stands for internal, which is the term I coined for the versions before the releases come along.
GoodLooking is a templating engine, which means it helps you to keep your php code seperated from your html. You'll have one file where you do your php programming and one which is the template. Then you need a couple of lines to tell GoodLooking which file to use, and what variables it should use, which can be in a third file, but can also reside in the same file as the programming logic.
Say you have a script that gets the user's first name, last name and birthday out of the database and put them into the variables $firstName, $lastName and $dateOfBirth. Now we write the following code to use LookingGood:
Compiling.
All of it worked, but it was slow. A few hundredths of a second does not appear to be too much, but in reality it is, if you are getting a number of views on your website per second and it's running on a host that's doing other things as well. A more complicated site than the ones I tested may really bog down a server if the work has to be done each and every time.
So, now it only does once, until you change the template, and then it does it once again. That one time it saves a file, which is basically a very messy php representation of your website, which means it is fast to go from there to your full website. And the messiness doesn't matter, because you are not going to see this code at all. For that matter, you are not going to notice the fact it is being compiled this way at all, as all you do is as I wrote above in the example, the engine fixes the rest for you silently.
A working sample is seen on my site. This is the template (view source to see it decently), and I simply put some constants into the engine, and here you see the result in real time.
INT02 does not have much functionality asides the mentioned yet and it has a funny perk, if you had a compile, it will show how long that took in the source, and it will always show how long the interpreting (from the compiled template to the result take) in the the source in html comments.
I won't make GoodLooking available just yet, simply because it is really advisable not to use it in its current state. However, if you really are interested despite that, let me know (for example, you could write a comment here). The next planned version is INT03, which will have one extra feature, after that there's INT04 in which I make a lot of changes and tie quite a few loose ends together. Then, when I feel I am satisfied with that, I will make an alpha version, which will be available.
Alright, thanks for your time (I can imagine, that was quite a read) and see you again some other time!
GoodLooking is a templating engine, which means it helps you to keep your php code seperated from your html. You'll have one file where you do your php programming and one which is the template. Then you need a couple of lines to tell GoodLooking which file to use, and what variables it should use, which can be in a third file, but can also reside in the same file as the programming logic.
Say you have a script that gets the user's first name, last name and birthday out of the database and put them into the variables $firstName, $lastName and $dateOfBirth. Now we write the following code to use LookingGood:
<?phpNote that instead of calling registerVar three times, we could also have called registerMultipleVars once:
$lookingGood = new LookingGood('template.tmpl');
$lookingGood->registerVar('firstName', $firstName);
$lookingGood->registerVar('lastName', $lastName);
$lookingGood->registerVar('birthday', $dateOfBirth);
?>
$lookingGood->registerMultipleVars(array('firstName' => $firstName, 'lastName' => $lastName, 'birthday' => $dateOfBirth));In either case we could have the following Template (in the file template.tmpl):
<html>This could lead to a page named "Hello Jasper!", with the following:
<:- this page is a sample page, and this text is a comment (disappears from result) -:>
<head><title>Hello <: firstName :></title></head>
<body>
<h1>Hello!</h1>
<p>Hello <: firstName; ' '; $lastName :>, my database tells me your birthday is at <: birthday :>.</p>
<: if (firstName == 'Jasper') :>
<p>Have a nice day, Jasper.</p>
<:end if:>
</body>
</html>
Hello!Or if you're your not me, but John Doe, you would get a page named "Hello John!", that looks like this:
Hello Jasper Horn, my database tells me your birthday is at 11/04.
Have a good day, Jasper.
Hello!Well, those are simple examples, but it does really show what the engine is about. So.. INT02, what's new?
Hello John Doe, my database tells me your birthday is at 31/03.
Compiling.
All of it worked, but it was slow. A few hundredths of a second does not appear to be too much, but in reality it is, if you are getting a number of views on your website per second and it's running on a host that's doing other things as well. A more complicated site than the ones I tested may really bog down a server if the work has to be done each and every time.
So, now it only does once, until you change the template, and then it does it once again. That one time it saves a file, which is basically a very messy php representation of your website, which means it is fast to go from there to your full website. And the messiness doesn't matter, because you are not going to see this code at all. For that matter, you are not going to notice the fact it is being compiled this way at all, as all you do is as I wrote above in the example, the engine fixes the rest for you silently.
A working sample is seen on my site. This is the template (view source to see it decently), and I simply put some constants into the engine, and here you see the result in real time.
INT02 does not have much functionality asides the mentioned yet and it has a funny perk, if you had a compile, it will show how long that took in the source, and it will always show how long the interpreting (from the compiled template to the result take) in the the source in html comments.
I won't make GoodLooking available just yet, simply because it is really advisable not to use it in its current state. However, if you really are interested despite that, let me know (for example, you could write a comment here). The next planned version is INT03, which will have one extra feature, after that there's INT04 in which I make a lot of changes and tie quite a few loose ends together. Then, when I feel I am satisfied with that, I will make an alpha version, which will be available.
Alright, thanks for your time (I can imagine, that was quite a read) and see you again some other time!
Tag Cleansing
Not so long ago, I had posts with tons of tags each, and no two of them shared a tag (alright, that's exaggerated, but still, it's partly true and that's bad enough).
No more!
I just cleaned up my tags. I am now using tags as they should be used, so readers can find related posts.
Anyway, I have an important post that is going to bury this one again, so I am not going to spend too much time on this one. Just be sure to read my important (=next) post!
No more!
I just cleaned up my tags. I am now using tags as they should be used, so readers can find related posts.
Anyway, I have an important post that is going to bury this one again, so I am not going to spend too much time on this one. Just be sure to read my important (=next) post!
Saturday, July 25, 2009
T_PAAMAYIM_NEKUDOTAYIM
I just received a brilliant error from php:
Parse error: syntax error, unexpected T_PAAMAYIM_NEKUDOTAYIM in /home/a5400048/public_html/Compiler.php on line 551.
I truly wasn't expecting a paamayim nekudotayim either. Further inspection showed it actually just meant "COLON". Php....
What I had done was typed "$class::const", while I actually just meant "class::const". It's that they told me where to look, because that error message is as descriptive as "Error: don't feel like continueing on some statement."
Parse error: syntax error, unexpected T_PAAMAYIM_NEKUDOTAYIM in /home/a5400048/public_html/Compiler.php on line 551.
I truly wasn't expecting a paamayim nekudotayim either. Further inspection showed it actually just meant "COLON". Php....
What I had done was typed "$class::const", while I actually just meant "class::const". It's that they told me where to look, because that error message is as descriptive as "Error: don't feel like continueing on some statement."
Wednesday, July 1, 2009
Land of Manuals: Factories
Alrighty, I just thought I would pop in and do another installment of the Land of Manuals. Let's start off with a quick recap of what we talked about.
This series takes place in a strange world known as "The Land of Manuals". In his land there are four types of people:
A good place to start writing about Factories is the service door. Now, in this world one would expect a rather boring door used only by employees. However, in the Land of manuals, it is much more than that. It is where wandering souls (oh, I didn't tell you about those, did I... well just don't worry they aren't really important anyway) are picked up from the street and become Workers. When there's work to be done and the factory has not yet reached its Worker limit, they pick up more wandering souls from the streets and get them to be Workers, when there's more workers than work, they will thrown out the same way they came.
But who does that you ask? Well the management. Let's see who we could use for a management. Writers? No. Rich? No. Rebels? No way. Workers? Check!
So it's workers again, 'ey? Well, yes the Land of Manuals isn't all that complicated, you just don't have many choices beyond the Workers here.
How your management works is decided by two major factors. How it works exactly is a topic for a later time, right now I will just list these factors. First off there is the structure of your factory. In general lines most factories are the same, but take a look at for example the inside of the management's office, and you will find way more changes. Nowadays only a few types of factories are widely used, but in the past many more have been used. This was actually the reason for creating uniform management manuals. The uniform part basically means that you will need a different version of management manual Y if you are using a different factory, but once you are running UMM Y, it appears everything works just the same as all other factories that use UMM Y. There are only a few widely used UMMs.
The main reason for using management manuals, and a management that is, is that it makes things a lot easier for Writers. If every time a Writer wanted to write a manual he or she would have to spend a considerable amount of time writing about getting Wandering Souls from the streets and making them workers, there would be very few manuals, so instead we leave such things to the management.
Once a worker is inside, he or she gets a shirt on which signifies what language he or she will be speaking. Say you need a manual written in English to be done which needs ten guys working on it, (they actually have different languages, but for now ours will do for examples) your management will make sure that they get you ten workers that speak English. However, two of them may also speak German, while three speak French and six of them speak Dutch as well as English; the shirts are just to make things a little easier, they will now know in what language they ought to communicate.
Workers work in teams. The composition a manual needs (one they need at least and one they would like to have, usually) is written on the manual and is there for the management to read. They will find the workers to form such a team and assign them to one of the many, many rooms that are in the factory, where they are left to do their job.
There is often a lot communication between teams or between a team and the management. For example, if a team needs access to a certain book that's in the factory's (yeah, factories have their own libraries, its a strange world), they will tell so to the management and the management will put a library team on it. Note that this all goes according to the manuals, though. The manual those that need the book are using will need to say "ask the management for that book" rather than "pick up that book". And the management's manual will say that if one asks for a book correctly they should put a library team on it - and it also tells them the composition of such a library team.
That's basically all I wanted to tell you about factories for now. There's a few more general concepts to discuss, but from there we will be able to take the perspective of the writers, which is what this series is all about.
This series takes place in a strange world known as "The Land of Manuals". In his land there are four types of people:
- Workers: they do whatever a manual tells them, no more no less
- The Rich: they are rich and they are stupid; autonymous, but stupid. They have their own factories
- The Rebels: they are rich, but they are smart. They intend to do wrong without breaking the laws, which are enforced strictly but very literally
- The Writers: they write manuals
A good place to start writing about Factories is the service door. Now, in this world one would expect a rather boring door used only by employees. However, in the Land of manuals, it is much more than that. It is where wandering souls (oh, I didn't tell you about those, did I... well just don't worry they aren't really important anyway) are picked up from the street and become Workers. When there's work to be done and the factory has not yet reached its Worker limit, they pick up more wandering souls from the streets and get them to be Workers, when there's more workers than work, they will thrown out the same way they came.
But who does that you ask? Well the management. Let's see who we could use for a management. Writers? No. Rich? No. Rebels? No way. Workers? Check!
So it's workers again, 'ey? Well, yes the Land of Manuals isn't all that complicated, you just don't have many choices beyond the Workers here.
How your management works is decided by two major factors. How it works exactly is a topic for a later time, right now I will just list these factors. First off there is the structure of your factory. In general lines most factories are the same, but take a look at for example the inside of the management's office, and you will find way more changes. Nowadays only a few types of factories are widely used, but in the past many more have been used. This was actually the reason for creating uniform management manuals. The uniform part basically means that you will need a different version of management manual Y if you are using a different factory, but once you are running UMM Y, it appears everything works just the same as all other factories that use UMM Y. There are only a few widely used UMMs.
The main reason for using management manuals, and a management that is, is that it makes things a lot easier for Writers. If every time a Writer wanted to write a manual he or she would have to spend a considerable amount of time writing about getting Wandering Souls from the streets and making them workers, there would be very few manuals, so instead we leave such things to the management.
Once a worker is inside, he or she gets a shirt on which signifies what language he or she will be speaking. Say you need a manual written in English to be done which needs ten guys working on it, (they actually have different languages, but for now ours will do for examples) your management will make sure that they get you ten workers that speak English. However, two of them may also speak German, while three speak French and six of them speak Dutch as well as English; the shirts are just to make things a little easier, they will now know in what language they ought to communicate.
Workers work in teams. The composition a manual needs (one they need at least and one they would like to have, usually) is written on the manual and is there for the management to read. They will find the workers to form such a team and assign them to one of the many, many rooms that are in the factory, where they are left to do their job.
There is often a lot communication between teams or between a team and the management. For example, if a team needs access to a certain book that's in the factory's (yeah, factories have their own libraries, its a strange world), they will tell so to the management and the management will put a library team on it. Note that this all goes according to the manuals, though. The manual those that need the book are using will need to say "ask the management for that book" rather than "pick up that book". And the management's manual will say that if one asks for a book correctly they should put a library team on it - and it also tells them the composition of such a library team.
That's basically all I wanted to tell you about factories for now. There's a few more general concepts to discuss, but from there we will be able to take the perspective of the writers, which is what this series is all about.
Sunday, May 17, 2009
Say "Eye" for Prism
Haven't heard of Prism yet?
Alright, so I have my first render for Prism. It's not much, but it looks pretty good if you ask me. It's an eye!
This time this blog is a few hours behind newgrounds and deviantArt, where I also publish stuff related to Prism, but I promise that won't always be the case.
As for that, I am not even promising that everything will always be published on all three of the media - though when it comes to renders they probably will (for now at least...).
Without further ado:
The upper image is the final render of the eye (at 4 NURMS iteration for those who want to know), the lower-left image is a wireframe of the same setup (alright, alright, only 2 NURMS iterations, but that's because it would get too cluttered otherwise) and the lower-right image is the wireframe of the model as I modeled it (without NURMS, that is).
I hope you liked the brief preview!
Alright, so I have my first render for Prism. It's not much, but it looks pretty good if you ask me. It's an eye!
This time this blog is a few hours behind newgrounds and deviantArt, where I also publish stuff related to Prism, but I promise that won't always be the case.
As for that, I am not even promising that everything will always be published on all three of the media - though when it comes to renders they probably will (for now at least...).
Without further ado:
The upper image is the final render of the eye (at 4 NURMS iteration for those who want to know), the lower-left image is a wireframe of the same setup (alright, alright, only 2 NURMS iterations, but that's because it would get too cluttered otherwise) and the lower-right image is the wireframe of the model as I modeled it (without NURMS, that is).
I hope you liked the brief preview!
Saturday, May 16, 2009
Prism
Man, I really thought I had the answer - what I am talking about in the last post, that is (The Land of Manuals). But just see how much time has past between this post and that one - and it appears it was a failed attempt.
Well, maybe it was. But that does not mean I am going to stop using this blog, nor that I will discontinue the "Land of Manuals."
I'll see if I can find some time today or tomorrow in order to write the first installment of the series (episode isn't quite the word, installment is a natural fit though ;). However, currently I am busy working on a new project: Prism.
I am not quite telling you much about it just yet - but I can tell you it will supposedly become a flash movie series. Those who know me in real life might know, I cannot draw. If I have a ruler and can look at what I am drawing every two seconds AND the shapes are easy, I might produce something that is recognizable (NB: that is, I have (and take) a lot of time to work on it as well). That means I won't be able to produce a nice flash movie (let alone a series), right?
Wrong. I can't draw, but I am not going to draw. I am going to model it in 3D. I am going to make models of everything I want in the movies and animate it with the models - and when I rendered a movie out of that I will convert it to flash.
It does take forever, though (I have spent a great number of hours on a single eye socket now...).
Well, maybe it was. But that does not mean I am going to stop using this blog, nor that I will discontinue the "Land of Manuals."
I'll see if I can find some time today or tomorrow in order to write the first installment of the series (episode isn't quite the word, installment is a natural fit though ;). However, currently I am busy working on a new project: Prism.
I am not quite telling you much about it just yet - but I can tell you it will supposedly become a flash movie series. Those who know me in real life might know, I cannot draw. If I have a ruler and can look at what I am drawing every two seconds AND the shapes are easy, I might produce something that is recognizable (NB: that is, I have (and take) a lot of time to work on it as well). That means I won't be able to produce a nice flash movie (let alone a series), right?
Wrong. I can't draw, but I am not going to draw. I am going to model it in 3D. I am going to make models of everything I want in the movies and animate it with the models - and when I rendered a movie out of that I will convert it to flash.
It does take forever, though (I have spent a great number of hours on a single eye socket now...).
Tuesday, March 17, 2009
Something To Write About
Wow, I think I have just set my record for not posting here. I have a remedy, though: something to write about. Mostly this blog has been about... well... nothing at all really. However, I have a series of posts planned, as I came up with an idea a while back. It's called "The Land of Manuals".
In this land the people can be divided in four groups. First there are the workers. Workers do not do anything unless they have a manual on how to do it. If the manual instructs them to do the wrong things, they will do the wrong things. Workers often reside in factories, but factories are not like factories we know.
Second there is The Rich. The Rich are rich, most of them even have their own factories. Granted, their factories usually aren't as big as the ones owned by corporations, but factories are factories. Another trait all the rich share is that they are stupid, incredibly stupid. They can handle autonomously and they don't expect manuals that they have to follow letter by letter as the workers do, but that's not a good thing; it means that they will probably do something wrong if it is at all possible.
The third group is the rebels. Most of the rebels are also quite rich and have their own factories, but they will do what they can to make things go wrong. Luckily there is some strict law enforcement going on, so they have to find the ways to break the system without breaking the law. This is all possible because the law enforcement is done by workers, meaning something just is or is not allowed - there is no common sense involved.
The last group is the one I am going to take the perspective of, they are called the writers and what they do is writing manuals for workers. You will know more about these guys soon enough...
Like the idea? Got an idea where I might be going? Comment!!
In this land the people can be divided in four groups. First there are the workers. Workers do not do anything unless they have a manual on how to do it. If the manual instructs them to do the wrong things, they will do the wrong things. Workers often reside in factories, but factories are not like factories we know.
Second there is The Rich. The Rich are rich, most of them even have their own factories. Granted, their factories usually aren't as big as the ones owned by corporations, but factories are factories. Another trait all the rich share is that they are stupid, incredibly stupid. They can handle autonomously and they don't expect manuals that they have to follow letter by letter as the workers do, but that's not a good thing; it means that they will probably do something wrong if it is at all possible.
The third group is the rebels. Most of the rebels are also quite rich and have their own factories, but they will do what they can to make things go wrong. Luckily there is some strict law enforcement going on, so they have to find the ways to break the system without breaking the law. This is all possible because the law enforcement is done by workers, meaning something just is or is not allowed - there is no common sense involved.
The last group is the one I am going to take the perspective of, they are called the writers and what they do is writing manuals for workers. You will know more about these guys soon enough...
Like the idea? Got an idea where I might be going? Comment!!
Subscribe to:
Posts (Atom)