I remember some thread about sporadic OzoneAsylum downtimes, and slowdowns.
Stuff happens, web applications have to stand large amounts of users and such, but...
There is something that can be done about it.
I've learnt that planning is extremely important when it comes to software development, and the immense effort by TP has gone through so many changes, tips, ideas, etc. Such an awkward process that
while I fully trust his coding ability, I am wondering wether the grail is giving it's full potential or not.
So, my idea here is to:
- lay down UML diagrams for the grail as it currently is. (a bunch of hours, two, three max)
- correctly and comprehensively stress test the Asylum to identify bottlenecks. (a one hour test/log phase)
- relating the diagrams and bottlenecks to flawlessly find areas of improvement.
Such bottlenecks cannot be summed up to this or that procedure being too slow, I am talking about general software design here: all the things I thought I had to manually investigate and test in the past
can be forecast and planned with a proper use of modelling techniques.
I am not putting in question the grail as it is, either, just wanting to optimize what could be optimized.
------------------------
A real world example:
- it's a known fact that db connection for a web app has to last as short as possible
- in general, this translates to web pages that release a connection to the connection pool as soon as it is not in use anymore
Workflow: user does action => action creates query => a connection is opened => query is commited => the connection is released
That's great.
BUT:
- writing to a text file is in general faster than accessing a db
- therefore, sql queries could be "packed" and cached to one big file
- every once in a while, a cron would call a php script that would swallow the cached queries file, and commit the associated SQL queries
Workflow: users do a lot of actions => action create text file entries => a connection is opened every once in a while => stored queries are commited => the connection is released
The global load would be more balanced towards file storage, vs. db storage and connections, for instance.
The global memory management would be improved.
This real world quick sample is not flawless, one would wonder "how do we go about making the cached data directly available to the public?" Or stuff like that.
I have answers, but I'll stop before this post gets too long to read.
The idea behind this whole thing is: a faster forum using accurate modelling techniques.
quote:I remember some thread about sporadic OzoneAsylum downtimes, and slowdowns.
im pretty sure these were caused by dreamhost and not the grail software.
quote:writing to a text file is in general faster than accessing a db.
yes it is. cause writing to a db is also writing to a file + the db engine routines.
and if im not mistaken, all pages at the grail software are therefore rendered to files everytime someone changes something.
quote:
im pretty sure these were caused by dreamhost and not the grail software.
Well, what about adding five times the speed to a reliable dreamhost then? It's a benefit anyway.
I mean: I don't question the stability of the grail, I don't question this at all, but the fact dreamhost is not reliable is all a more reason to improve the grail.
quote:
yes it is. cause writing to a db is also writing to a file + the db engine routines.
and if im not mistaken, all pages at the grail software are therefore rendered to files everytime someone changes something.
You are mistaken, and that's a good reason to clarify things on a larger scale.
One, among the twenty differences I could quote off the top of my head is: db query = dedicated db server = (random/unpredictable) transfer times added to the text processing.
VS directly writing to the very same physical location, aka the web server and a text file (constant response time)
I could quote twenty more differences between reality and assumptions.
But it would be easier for me to make an UML plan, it explains it all ;
And if you want to more about UML, check this: What is UML?
A silly/funny and yet terribly powerful diagram to make is the "use case diagram": UML use case diagram
And drawing scenarios allows things like "user A slaps user B with a trout" to turn into reality (an option to slap someone with a trout)
Extracting such diagrams from an existing thing like the grail would be useful forever: future maintenances, upgrades, etc.
It would be easier than drawing it from scratch.
The resulting UML class diagram would mostly map to functions, php files, and such, that already exist.
All this can happen automagically, without even "thinking" it, by just applying a set of rules to an existing structure.
UML is to software design what web standards are to web design.
I want the people here to develop such a set of diagrams, because UML goes this way: real world situation => software.
In our case, real world situation + software => faster software.
For example, and to take the first steps, one thing to do would be defining actors, internal or external to "the system", and we already have them:
database, user, system, moderator would be some of them.
I am not sure if interface widgets would be actors in our case, but we could then add: button, post box, slimie, etc.. to the list of actors.
Next, the use cases, and a scenario.
Again, these are the tasks we do daily.
A sample scenario would be:
* user enters the asylum
* user browses forums
* user browses threads
* user creates new post
* user supplies credentials
* user submits post
Real world tasks we do daily. This is one sample sequence, but the full detailed scenario would also cover alternatives (user edits post), translated in very simple, human words.
Once we have the actors and the scenario, guess what? We can really effectively draw the use case diagram, and a couple of others that SHOW relationships between entities.
Now it's time to transform these diagrams into class and interaction diagrams, aka code descriptions.
And guess what? We already have a codebase to evolve from.
At this point in the "community process", for lack of a better word, the differences between the uml classes diagram and the existing code would probably be small.
And they would perfectly highlight areas of improvement.
That's the basic idea:
1) collectively outlining what the Asylum is in the real world
2) some experienced users (coders) would help turning this into a handy class diagram
3) TP's main, or only part in this would be comparing the collectively created class diagram to what already exists
Add a comprehensive stress test, a collab between any finglonger and any user(s), or a single software run automatically from a single pc, and you'd know HOW to improve.
Highlighting areas of improvement + knowing how to improve == 99% of the optimisation job.
Mainly done by.. the whole-
quote:No. Not at all.
I want the people here to develop such a set of diagrams
and how would the people here be able to develop this set of diagrams, if they do not know the grail's source code?
and... sorry... but... it's probably my bad english or the late hour here, but i dont quite get what you are trying to say here.
err, what do you mean by "collectively outlining what the Asylum is in the real world", and how can that lead to "a handy class diagram" ?
And to tie both ends of the this thread, back to the first sample:
- text files as a cache would become relevant only if the database response times appear as a bottleneck
- database response times will appear as a potential bottleneck only if theyre importance is critical to the system
- theyre importance to the system will vary with the amount of use cases and relationships they are involved into
- a use case diagram would make this obvious, or not
My. Ok, I'll make it simple, let's talk stoneage english:
Me user, me goes to Asylum, me browses forums, me browses threads, me submits new post, me happy!
I guess you know the sequence of movements and actions you do to actually post?
Well, *ding*: this sequence of movements IS part of UML modelling.
I guess you know the bits that make an Asylum? I mean, let's describe an Asylum page in stoneage english:
Me sees Asylum page, me sees logo, me sees forums, me sees buttons, me sees cells, me sees labels, me sees search box. ArrrrrhHHhhHHH!
And guess what? Our caveman just laid out the list of actors in the asylum recipe. OOH, another UML fundamental element.
There's nothing more to do from the users, nothing but methodically thinking to themselves (what is there in an Asylum? how do I go about doing <this or that> at the Asylum?)
-------------------------------------------------
I am merely kidding, please don't take it personal: these aren't hard concepts, it's just a matter, for you, of understanding that
anybody can describe what he wants of a dream application easilly.
After a night of rest, check the following for the answer to:
and how can that lead to "a handy class diagram" ?
Because once you have described the bits you see with your eyes in an Asylum (Actors) and what you can do at the Asylum (Scenario),
you can very easilly interconnect them.
Caveman english:
"me presses button under postbox! Me sees new post in thread! Me happy"
This is a connection between actors.
Users -> presses -> button
Users -> reads -> thread
This is a use case diagram, connecting the bits you've laid out.
And once you have such a diagram, made of little labels, characters and arrows, comes the tribe shaman,
who applies a set of plain - but code savvy - rules, and bang! You got a comprehensive class diagram.
Or a couple of others that you can use to implement the code right away.
well, if that helps you optimize the grail, then what are you waiting for?
( and just for the record: if my last 5 years at universtiy havent been completely without purpose, UML is bit more than that. infact it follows very strict specifications which you may download here. )
* well, if that helps you optimize the grail, then what are you waiting for?
Being sure that it will serve a purpose that will please and be accepted by others.
It IS a good thing to do, an excellent thing to do, it will matter a lot for the future of the Asylum as well, when it will have to get a new skin again, using maybe other scripting languages (it has gone from cgi/flat files
to php/databases already, who knows about the future?)
My last three years in uni have been useful in that they helped develop a flexible mind:
* part of the uml diagrams are not needed for a small / medium application (we don't give a damn about how many database servers, how they interconnect, etc.)
* web standards follow strict specifications, is html that hard?
You get my point. Rigor doesn't mean complexity: it means rigor.
We're not redoing Windows here, so we only need rigor in small things.
Trust me, I got four UML driven projects on my hands at the moment, I have "an idea" of how it works.
Ah yeah, I can, and will create a faq entry for the scenario, but I sure will miss many cases if the community is not involed.
For example, the rss feed I never use.
Ok, there now are a bunch of faq entries for this whole stuff.
As I have talked way too much already, I'll leave it up to you for now,
and will get back at it regularly.
quote:
but then you would have to add that into the scenario
anyway, i for one would apprecciate it much
Well, the scenario doesn't speak about how to implement it, but it still makes it possible and easy.
But updates should come later, or in a separate faq entry: we're trying to outline what exists.
Still, the fact of saying "user slaps other with huge trout" includes it in the scenario without any restriction. Can be a slimey, can be a "hand punching a hole into a thread cell,
holding a trout and slapping it at somebody else in the thread". Interface-wise, this could be made using Flash and js.
Design wise, this can be thought of, planned and freely included in a scenario.
That's why anyone can create a scenario once you understand a bunch of basic "readability" rules.
Upon turning the use case diagram into a class diagram (when the major geeks come into play), the implementation is chosen, and is made a "lot" easier by this careful planning.
Because just as a storyboard for a movie, we know *exactly* where the new thing belongs.
Grumble, don't get me wrong, but the first question, I have already answered and rephrased.
Anyway,
It would flesh out all possible uses of the Asylum.
This alone allows spotting bugs.
In the course of this, we'd have to define actors, which would also flesh out all fundamental elements of the Asylum.
In other words, the resulting, and real-world oriented diagram would simply be the functional skeleton of the asylum summed up in a bunch of plain words, and a couple of arrows.
Again, when the actors are "message", "thread", "forum" in the real world language...
And when we know which attributes they have, and how they interact with each other...
When we have the scenario, and draw the arrows that represent all the interactions...
Then actors become objects, interactions become methods, and attributes become properties.
Objects, methods, properties. <------------------------ re-read that 1000 times: actors => objects, interactions => methods, attributes => properties, A REAL WORLD SITUATION, DEPICTED IN SIMPLE WORDS,
JUST HAS BECOME THE PLAN OF AN APPLICATION IN A TWIST OF HAND.
An object oriented class diagram.
Not ANY class diagram, an IDEAL way to map the real world scenario into an OOP diagram.
I cannot emphasize enough on the word I-D-E-A-L, that's the crux, that's the true answer to your question: mapping real world to OOP this way
makes the result excellent, and easy to improve without implementing a single line of code.
Compare IDEAL to CURRENT, and you have your FLAWS outlined.
And there you go with situations like "oooh, wait, we wanted that feature to work this way, but something's gone wrong in the actual implementation."
Or "heeeeey... I can achieve this with less steps".
Useless methods will disappear, intricated methods are shred into smaller/faster/more flexible bits, the general structure moves from "implemented with coding skills" to
"implemented with a perfect plan". I can't explain it with other words, you have to try it out or I have to show you the next steps if you're not getting it.
...
In a recent app of mine, I had a huge method called "drawHelix" I took from a Nehe tutorial.
This awful thing basically drew a 3d helix on the fly, and radial blurred it using several passes, all in one method, all in a single main.cpp file.
Having applied UML and reasoning to this Nehe thing, I now have a class called "filters", with a "drawblur" method.
I have a class called "Object" which defines a template 3d object.
And a class called ObjectFactory, which generates primitives.
The result: 3d primitive is generated ONCE (as opposed to on-the-fly), which makes for a good 100% speed improvement, probably more, didn't benchmark.
AND the blur can be applied to ANY primitive (as opposed to being stuck to the Helix thing).
As an engineer in training by night, I have modelling courses all year long, it has lasted three years so far, and I have spent the last months
working on four quality applications. Two with different teams, two on my own.
I also deliver quality support services, in my job, to Philip Morris, and trust me, they like quality.
I grant you a point though, for I have passed a heavy "IT processes (ITIL)" exam the other day,
and it tends to make me see life in terms of "structures and relationships".
Seriously, though.
These things just work, I apply them day to day: how many times in my life did I completely rewrite a procedure? Or how many times did I throw one away
because it had become irrelevant and useless as the application had grown?
ALL this wasted time disappears with a solid plan: you're not "benchmarking two ways" and "implementing them" all the time, you have such a solid plan
you can shift this or that detail and immediately see how it impacts the whole.
Why else? Because it fucking makes life easier, applications faster and better, and I have a proven experience with it.
And because I'd love to visually slap you with a huge trout right now.
*Slaps Grumble silly with the trout of all trouts*
if im not mistaken, all pages at the grail software are therefore rendered to files everytime someone changes something.
You are mistaken, and that's a good reason to clarify things on a larger scale.
One, among the twenty differences I could quote off the top of my head...
Just a short intervention as he isn't quite, actually.
The last 100 or so threads that have been viewed are cached and solely accessed as static files by those who do not add their own reply, reducing the number of DB queries quite a bit already.
Can't believe I read through all that stuff above (and the tutorial) just to realize that UML is just "common sense" put in a more formal language, ...and diagrams lol.
I'm not going to elaborate further on that since it's 06:10am here and I don't feel like writing an essay at the moment but here's my opinion in ûber short version:
As I see it, what _Mauro's trying to say with this whole UML thing is that the Asylum code should be re-organized at a structural level. Which would eliminate any unneccessary processing/traffic/etc, like in the example with the helix. However, I doubt that hasn't already been done atleast once, and the gain from doing it again would be only marginal. I say blame the host
OK, not my shortest post, but atleast I got some finger exercise before crawling to my bed...
Well, kuckucs, this doesn't really spoil my point:
quote:
The last 100 or so threads that have been viewed are cached and solely accessed as static files by those who do not add their own reply, reducing the number of DB queries quite a bit already.
Is almost exactly what I was thinking about above without, obviously, knowing anything about the code.
Which shows I have experience. It's all a more reason to trust the fact I have something to share about this whole thing.
As twoD says, UML is common sense made formal AND, more importantly, standard.
TwoD, I assume there are plans, indeed, notes, etc. I don't think (but this merely is an assumption) they've been made by the UML standards.
----------------------------------------------------------------------------------------------------------
Btw, umlizing an existing application is also involved into reverse engineering it, so it's not surprising I came up with an optimisation that
has already been implemented: I "guessed" the code and bottlenecks by only guessing part of the related diagrams.
Still, about optimisations..
There probably are many TP, and I, and others, completely missed (unless finglongers have a solid set of diagrams giving a comprehensive/readable overview).
----------------------------------------------------------------------------------------------------------
But let's forget the optimisations for a while: what about simple maintenance?
Ten years from now, TP has been abducted by aliens, Emperor has been caught by Flash Gordon, and databases and php have become obsolete.
What to do, what to do? A new finglonger would hurt himself badly if he tried to take over the Asylum upgrades and maintenance
based on plans that maybe were very clear to TP, but weren't drawn according to standards. Eg. He could and probably will miss many many things.
Whereas UML will almost certainly still exist, by then, with a backwards compatibility.
Even worse: lightning has struck both the Asylum server and backup servers! Gosh, the Asylum has ceased to exist
No need to panic, there is a clear UML plan of what to do to get an identical Asylum up and running in no time:
which packages, methods, classes, the whole thing.
The same if a replica of the Asylum has to be made, with small edits and new options (for example for the gn).
The same if TP wants to sell his services, and demonstrate the work behind the Asylum, and a clear structured approach to that immense work:
a couple of diagrams, and new employer/customer will "see" what he can do.
----------------------------------------------------------------------------------------------------------
See? My point is not to say "I know better than you" or "can do better than you", my point is not to despise Grumble, my point is not to get myself involved
in the Asylum and "take it over" (muhuhahahaha) (I am waaaay too lazy, moody, and busy to maintain the Asylum code on the spare time I don't have - unless a hand is required for a given task,
which is all I have the time to give but would give with pleasure).
My point is "we can all play a role in getting to KNOW and DRAW the Asylum
structure and keep it for an eternal record in order to use and reuse it as needs arise".
And, a secondary point is: this is proactive maintenance, because needs WILL arise, sooner or later.
For example, if someone wanted to "compact" the forums
Well, if I have managed to somehow get you interested in modelling techniques, half of my goal has been reached, which is good already.
TwoD, I can't believe I have actually written all that you read above (my fingers should hurt by now), but I am glad you took the time to read.
Off to watch "Ghost in the Shell 2 : Innocence".
Ah, and in case some of you would think "what's up with that pompous fuck questionning our work?" I am just trying to add some value to it,
which instead shows respect. A cool app deserves a cool plan and other helpers for it's future life and growth.
If the price for me is to rave like a lunatic and risk misunderstandings, it doesn't matter.
------------------------------------------------------------------------------------------------
Grumble, it is true: I have suggested a possible improvement as an example of how modelling can impact an application.
AND at some point in developping the actual app, the coder has effectively implemented that.
So tell me, how is my guessing what actually exists ridiculous?
Let's specifically adress your wounded ego issues:
quote:
yes it is. cause writing to a db is also writing to a file + the db engine routines.
and if im not mistaken, all pages at the grail software are therefore rendered to files everytime someone changes something.
Down there in the c++ world, writing to file = getting a pointer to a free memory space and putting data in it.
Down there in the c++ world, querying a db is something else altogether: it is passing an interpretable query to an engine which will process the query, allocate the required memory,
and store the data in a non-linera, db specific way. It's a lot more complex.
So, your first assumption is wrong: writing to a db != writing to a text at all, it doesn't equate in terms of complexity, nor in terms of elementary instructions to use.
THEREFORE, but what does that therefore stand for? TP has implemented a text file cache because he thought writing to db is the same as writing to a text file?
Pardon my poor english, as you said before, but there's room for misunderstanding there... AND you actually ARE mistaken about the text file and db access comparison.
Now, I have asked you not to take it personal, but indeed, if I am giving you emotions a plenty, I am sorry, but there's nothing I can do about it.
So leave the thread, have a couple of coffees, and get back at it when you can actually read it without feeling hurt.
- Sigh. A last attempt before I give it up altogether.
Ask yourself..
* Do I like and respect web standards?
* Do they help improve my work?
* Do they help me communicate with other webmasters/designers/whatevers?
* Would I -ever- have thought css based designs would be a lot more effective and smaller in size than equivalent html with tables?
* Would I -ever- have foreseen the benefits of XML when it came out?
* Would I now be able to do anything, web-design wise, which doesn't involve a little xml, and a lot of css?
* Does InI have anything to win for himself in openning such a thread and risking misunderstandings?
And when you're done with these questions.
Transpose them to UML and the coding world.
Why do you think the WHOLE industry has adopted a set of rules defined over 700 pages?
Do you think I am the only advocate of UML? just fucking google it.
-------------------------------------
@Grumble, if you had told me "I am lazy and I don't give a fuck about spending the time to help make an Asylum spec / tech doc/ plan", ok, that would be fine. You seem to care, but only enough to misunderstand and
get emotional and agressive.
@TwoD, boy, I am not assuming UML would make things better, I can't forecast anything witout a plan, but it DOES make things a lot better wherever it hasn't been used previously, always.
As I wasn't ASSUMING the 3d grid thing would make collision detections faster.
If you get to implementing that option, let me "know", but I already know.
It has become a standard because one can blindly rely on it, it is the result of years of coding experience of the development industry, it's not MY invention,
it's impact is not MY invention and is independent of myself and my own experience.
I KNOW it will improve things because it is it's purpose, it is the de-facto modelling standard nowadays for oop, databases, and many other ares.
-------------------------------------
Just exactly as you now all know that a css based design WILL be more effective than the css-less equivalent.
...Now, quite frankly, I've said it all. UML is basically common sense, but when you lay it out, THE FACT of laying it out helps.
Keeping your common sense in your cerebellum is the place where it is likely
to be less useful: putting it on paper makes it ten times more effective.
The Doc had a page about sketching and being able to "have an overview" before doing things, see if you can find it at http://www.ozones.com
Weadah and DG start by laying out the "big picture" and then digging into details. A PLAN, and THEN the actual work.
ALL webdesigners here use web standards. A PLAN and a sheer understanding of standards, and THEN the actual work.
Slime, when doing his js raytracer, had simply laid out the maths involved in raytracing as OBJECTS, he had intuitively laid out a typically correct object orientend program.
He had intuitively modelled reality through steps very similar to a UML approach.
In the Asylum, possible/probable results of making the plan standards compliant would be a constant response time, all the time, and 99.9% reliability instead of 95, a smaller - more readable code,
optimal load on all involved servers, less bugs, easier maintenance, easier upgrades (the trout thing), easier migrations (should a new db system be selected for instance), easier or automated maintenance (an auto-sink,
or mod-bot, call it what you want).
Tyberius Prime
Paranoid (IV) Mad Scientist with Finglongers
From: Germany Insane since: Sep 2001
posted 01-07-2006 13:15
Get a life.
Believe what you want to believe.
You could have gotten the grail code in the past and drawn your own diagramms - instead of trying to get other people to spend their time on them.
My time is too costly to spend time on something that will not improve things.
You do not identify bottle necks by adding another abstraction layer.
You use a profiler to find where your code is spending it's time.
I have done that on the grail a long time ago.
Your're right about me not being around forever - but finding someone who will serve the Asylum after me is either my or the Doc's job.
Do not trouble yourself with it.
Straight insult to start with. How low can you go? We'll see in the next steps.
>> My time is too costly to spend time on something that will not improve things.
That's honest. But wrong when it comes to improving things. Still, it is your choice and an understable one.
Btw, I am sad to know you don't even want to consider possible long term improvements.
I understand you do not give a fuck about the asylum now that it's up and running though.
>> You could have gotten the grail code in the past and drawn your own diagramms
I wasn't aware of precise modelling concept I am now trying to communicate, I was like you, on my own.
>> - instead of trying to get other people to spend their time on them.
What am I accused of here? WTF? I have gotten you to spend your time on the grail? Really? I have these magic powers?
So you're telling me I can magically say *Shazam* and have you do something for me. WOW!
>> You do not identify bottle necks by adding another abstraction layer.
UML is not about adding an abstraction layer, it is about optimally structuring an existing one.
And it outlines bugs, shortcomings, and potential bottlenecks before the actual implementation...
>> You use a profiler to find where your code is spending it's time.
In addition to having a well structured code and a DOCUMENT that describes that structure, PLUS you can forecast instead of profiling, which spares the implementation time.
Which spares a sheer amount of your precious time.
>> Your're right about me not being around forever - but finding someone who will serve the Asylum after me is either my or the Doc's job.
Do not trouble yourself with it.
I don't care who will do it, indeed it's not my business.
His business, and yours, would be made easier by adopting standards, that's merely an advice.
Just answer this one question: can you take an advice without whining and assaulting me?
I'll take this as a no.
I am merely EXPOSING facts here, wasn't this place's purpose allowing one to expose and share ideas about his passion?
Frankly, if taking the hint from me is too hard for you ego, if it makes you shake and shiver and wet your panties,
take it from IBM
If it's too demanding to your so humble and open-minded self, then you have my blessance, you may go fuck yourself and any other "hooo he's daring to propose improvements
based on industry standards" kind of person.
And say I spent the time to try to vulgarize this and open three fucking faq entries... hope some clever coder like TwoD at least benefits it.
_Mauro: I wouldn't mind if someone told me to "get a life" after writing all that text, but telling someone to go fuck themselves as a reply is a bit strong. Especially after waiting only 10 minutes for a reply. Maybe that's just because I happen to be drunk at the moment, but I doubt that lol
I think I'd have to agree with Tyberious Prime that UML could become "just another abstraction layer" if implemented on or instead of an existing documentation/flow chart/operation plan/whatever you call your notes and sketches. My experience is that suddenly changing your documentation routines can cause confusion if you have more people than just yourself involved. Even if UML is a standard I would not use it myself unless I had to beacause of bosse's orders or it is already used in the project in discussion.
UML is basically, if I have understood it correctly, a specific way of approaching application design just like TPM or 6S are industrial standards for keeping a good work-flow while keeping the factory floor and offices nice and clean. Yes, a bad description I admit but I think you get the point.
A factory which already has a good plan that works and leads to efficient usage of both machine and human resources to produce products of the right quality at the right price probably won't need another plan to improve their work. It might actually lead to a slight degree of confusion or exagurated concentration on the documentation instead of the finished product, thus a decrease in quality. Not that I know if anything of this actually applies to this place hehe
I hope you don't think I'm all negative about UML. I'm sure it could be very useful if used correctly from the beginning, especially when more than just a few develpoers/designers/planners/producers/etc are involded. So everyone's speaking the same language and have a clear outline to build on.
Hmm, I wonder if anything of what I wrote above makes sense and actually contain anything useful...
Anyway, I seem to post here everytime I do something stupid like not sleeping or drinking alot, think I'm gonna shut up from now on.
Btw, thanks for the nice words about me. Who knows, maybe I will benefit from it sooner than I think.
One thing I will say once, but something I personally believe: If you bitch and you moan and piss about in here, will you achieve anything by it? Will it make your desires come to fruitiion? Will it help you achieve your aims?
Is it, in the end, worth the time and effort you expend on writing these posts? Is it worth the energy to bite back when someone takes a snap at you?
The answer, I think you will find, is no. You don't achieve anything by biting or biting back. It's just another form of posturing, and a way to make yourself feel better about it all.
This isn't aimed at anyone specific, I'll say that right now. Yes, there is worth to be had in putting your case forward and being prepared to back it up. But be prepared ot back it up with calm, reasoned arguments, and if someone bites at you, ignore it. You only end up destroying your own case by biting back. It degenerates from an open debate on the pros and cons of an idea into a flame war which helps no one, in the end. So stop it before it starts, be prepared to pretend you didn't see things.
Now, this one part is directed somewhere specific: Mauro? TwoD is right, you waited all of 10 minutes for a reply from someone who already said they weren't going to reply. If you going to put things into a non-real-time format like this, at least be prepared to give people time to reply to you. 10 minutes is not time.
Back to being general; There is one thing I see a lot around a number of boards, and it's something that never fails to surprise me. This kind of non-real-time communication is perfect for calm- rational debate. Why? Because since by its very nature it is a protracted conversation, then you have time ot sit and think and be calm and rational. And if something does make you angry, then you have time to cool off and deal with it like an adult. But so many people don't. Try it, sometime. Anger is never a way to live, I know this. Anger breeds anger breeds anger breeds violence breeds violences breeds hate. Is hate how we want to live our lives? I know I don't want to.
Now, I stayed out of this because I am, at best, a very amateur programmer, so debates on the merits of this modelling language versus that, this access method versus that, well, that's not where I belong. So, like TP, I will bow out of this, and wish you all a good, calm day.
posted 01-06-2006 18:35
Glad you enjoy the concept.
