Universal Software Development Automation
Kalle Launiala
control the implementation from design level, but failed to
communicate it through.
What we discovered is universal and absolute software development
automation:
http://abstractiondev.wordpress.com/absolute-proof/
The references section explains how this applies immediately:
http://abstractiondev.wordpress.com/references/
The videos and downloads include full demonstrations of full
applications (mobile-client-server architecture stack automation,
Logical Operation automation and PowerPoint Add-In automation):
http://abstractiondev.wordpress.com/demo-videos/
http://abstractiondev.wordpress.com/downloads-and-technical-specs/
Project specification and design level this means that the items
described by CitrusADM overview (including the project structure) is
achievable:
http://www.citrus.fi/en/companies/citrusadm
Connection to specification (as well as enforcing aspects from there
is described here):
http://abstractiondev.wordpress.com/2011/09/27/measuring-user-experience-complexit/
And finally, I understand that not everyone likes the idea of getting
their "manual labor" automated. However the templates still require
the same exact amount of problem solving so the valuable work is not
wasted; it's just repeatable by those who cannot solve the original
problem, but need the solution.
This is achieved by making and distributing the abstraction-
automations:
http://abstractiondev.wordpress.com/all-in-open-source/
For those interested, enjoy!
Kalle Launiala, CTO of Citrus Solutions Oy
RonJeffries
And finally, I understand that not everyone likes the idea of getting
their "manual labor" automated. However the templates still require
the same exact amount of problem solving so the valuable work is not
wasted; it's just repeatable by those who cannot solve the original
problem, but need the solution.
Kalle Launiala
We have tested this on real-life developers with excellent results.
Kalle
RonJeffries
What's wrong for programmers automating their own job?
We have tested this on real-life developers with excellent results.
Ron Jeffries
Corey Haines
blog posts; there are a lot of words around abstraction and universal
and automation, but I'm not sure what they mean together. I watched
some of the videos before, and they seemed like xml configuration of
some components.
For me, I'd like to see a complete application built. I'd like to see
how to verify that the system works in a time-effective way (providing
the same value as a suite of automated tests). I'd then like to see a
small- + medium-sized feature added to it.
The way to get a lot people's attention (specifically mine, and from
the history of the conversation, a lot of peoplel on this list) is not
through a lot of documentation and descriptions and short video
examples, but by building a real-life application and showing how this
method makes it a) less error prone and b) more maintainable.
Thanks.
-Corey
> --
> You received this message because you are subscribed to the Google Groups "software_craftsmanship" group.
> To post to this group, send email to software_cr...@googlegroups.com.
> To unsubscribe from this group, send email to software_craftsma...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/software_craftsmanship?hl=en.
>
>
Kalle Launiala
base.
I don't completely understand what's wrong for an Office-Add-In
demonstration for a full application?
We have had very limited resources to bend over for any larger
demonstrations, however the methodology is fully solid.
It simply replaces any given code that human has to manually write
with automation. The automation gets its details from design level;
hence the information is completely pure and not distracted by "class
model implicit design".
The add-in example (although not visualized in pictures) is explained
properly in the videos (PowerPoint Add-In Architecture).
The XML is used as schemantic form of a data; you really can't get it
more standard than that.
The verification is explained on the links above; the Reference
section completely covers "the system is solid"; the template is made
by the very same people than would be writing the manual code. What's
the difference in quality there; other than more structured approach
of delivering the code as the meta-model enforces strict terminology.
Kalle
> >http://abstractiondev.wordpress.com/2011/09/27/measuring-user-experie...
Kalle Launiala
It is an universal automation solution. I claim it a breakthrough
innovation for a reason.
Programming is actually very deterministic process, when you look down
from the design-level; this is where you customize the meta-model as
you want and then let the generators do the job all the way to the
methods, where human starts to code the implementation.
The generators/templates are made and maintained the very same people.
The technology is by no means different than has been in Web-
applications for quite some time; markup replacement templates.
If you trust the computer to run your application, what's wrong in
trusting it to write the code for you as you've written the template
yourself as well?
Kalle
RonJeffries
If you trust the computer to run your application, what's wrong in
trusting it to write the code for you as you've written the template
yourself as well?
Ron Jeffries
Corey Haines
<kalle.l...@gmail.com> wrote:
> The problem is that the real-life project is on a customer-sealed code-
> base.
If you want to convince people to try out your tool, you have to put
the effort into building an application that isn't sealed.
>
> I don't completely understand what's wrong for an Office-Add-In
> demonstration for a full application?
The majority of people I know build applications, not add-ins to
Office. I'd also like to see examples of how you verify the system
works. How you maintain and add features.
>
> We have had very limited resources to bend over for any larger
> demonstrations, however the methodology is fully solid.
In the same way, we have limited resources to bend over for mining
through hard-to-understand documentation.
The methodology I use is fully solid, as well. That's why it will take
a bit more than just "mine is awesome" to interest me enough to spend
a lot of time.
> The add-in example (although not visualized in pictures) is explained
> properly in the videos (PowerPoint Add-In Architecture).
>
> The XML is used as schemantic form of a data; you really can't get it
> more standard than that.
XML is hardly cause to say something is standard. Standards revolve
around the actual schema, not the fact that you have nested
constructs.
-Corey
George Dinwiddie
On 11/25/11 2:36 PM, Kalle Launiala wrote:
> Programming is actually very deterministic process, when you look down
> from the design-level; this is where you customize the meta-model as
> you want and then let the generators do the job all the way to the
> methods, where human starts to code the implementation.
It seems to me that you've just moved the programming to "customizing
the meta-model."
- George
--
----------------------------------------------------------------------
* George Dinwiddie * http://blog.gdinwiddie.com
Software Development http://www.idiacomputing.com
Consultant and Coach http://www.agilemaryland.org
----------------------------------------------------------------------
Kalle Launiala
Not at all; please let me explain. All the below phases can have
changes applied to them within the single version-control changeset.
This is the key-difference that makes automation no-compromising one.
You can automate as small a part (be a single aspect through your
whole class structure) as feasible or even revert back to non-automate
it later on (we've done this as well).
There is zero risk involved; all you have is structured code; be it
manually written or automate-template generated.
But to the phases. You need to understand what you're designing, but I
think we all can agree that this is somewhat the baseline for making
any design at all.
Design Phase:
The design structure is described in meta-model; that is in this
methodology XML-schema based.
The design information itself but NOT_THE_IMPLEMENTATION of the things
(that is, what methods exist, what classes exist, what other
structures exist, what validations on domain model exist) is described
then with the XML that is strict bound by the schema.
Thus the design ALWAYS follows the meta-model implicitly; and is even
intellisense-supported (I'm sorry the videos are somewhat crappy, but
the "Using xxx Abstraction" is supposed to demonstrate this part.
Automation Phase:
Summarized: Think of the automation phase as someone manually
following strictly the instructions of how some certain implementation
is made. "We always define our classes like this, our interfaces like
this, the service-layer like this and so forth".
Template-generators use the pure design level information to
structurize the program/code. This is of course 1:1 match of the
design. It's not one-time-shot but continous part of the process.
Templates are coder-project-made (although great reusability within
teams/community/ecosystem can be achieved), so there is no compromise
of adjusting your code to someone else's. Templates are really fast to
make, yet they keep the code simpler to understand than basing on
traditional object-oriented approach of reusability.
Manual Implementation Phase:
After the automation, if the design phase introduced new structures,
the compiler might not be happy. For example if you introduced a new
method in your class, the automation created the method as properly
named and documented, but the implementation is missing.
This is where the manual code still has all the levels of freedom
available to do what it needs to do.
In this list, if you look at the "Using Existing Abstractions - Using
PowerPoint Abstraction":
http://abstractiondev.wordpress.com/demo-videos/
You see where the automation does it's trick and then the coder
finishes the job.
Kalle
Kalle Launiala
What I'm trying to say is that we can explain this very simply using
the languge that most on these forums understand really well.
Please meet me halfway, as currently your arguments sound like those
"project-management-economist" style ones.
I also understand if you don't feel that this methodology is "well-
enough-explained" for you to spend your time on it. I'm pretty much
alone and only person trying to scrape around the demonstrations and
explanations.
SC was claiming to seek and improve ourselves; I've managed to explain
this to quite a lot of people, who had the interest of hearing what
I'm trying to say and not challenge my message and claim "come back
with those claims when you managed to make that mainstream".
Kalle
P.S. Not to derail this thread, but I wanted to address your
arguments. Before either of us set up into battle positions, you might
want to revisit your arguments:
Office Add-In is a COM component; in our example made of pure C# code
using certain interfaces and base-classes. In my book it suits as a
demonstrational base for solving design-implementation level issues.
The latter demonstrations (Status tracking, documentation and
enforcing performance requirements) is a console application that
calls logical operation structure. Again; in my book it serves a full-
describing implementation demonstration.
XML standard is about schema definition and XML-documents. That's what
I'm speaking about here. Your arguments hold against that majority who
claim "they're standard because they use XML (without schema)". Your
argument is invalid here, because I specifically mean the XML standard
itself.
On 25 marras, 21:59, Corey Haines <coreyhai...@gmail.com> wrote:
> On Fri, Nov 25, 2011 at 1:33 PM, Kalle Launiala
>
Kalle Launiala
To XML standard I meant to write "we're standard using XML (with-or-
without schema)".
Regardless of that phrasing; the XML standard I'm speaking with this
methodology is the actual standard.
The self-defined-and-altered-schema is the main artifact that
describes the meta-model. I'm speaking about designing the SCHEMA
itself.
Kalle
Kalle Launiala
I wasn't familiar with Goedel's theorem before, so please allow my
answer with my interpretation of what I thought you were asking:
If you mean, is our proof "solid" but complex to prove (using
incompleteness theorem); the answer is no. This solid proof is very
simple and completely deterministic. The only input in the generation
is completely pure design-level information, that's form (the meta-
model) is completely controllable and modifyable by the designing
architect (with all the flexibility of source-control branching and
merging applying - that is safe to explore and undo or apply
succesfully).
You can think of keeping all the levels of freedom, but allowing YOUR
SELF MADE deterministic code-generator take off the load of any source
code that needs to be present in your development during that certain
check-in phase.
And because the generator is YOUR code as well, you don't have to
trust it with anything more than your comfort zone is.
Then on the flip-side; the more information you can constrain on the
logical pure design form; the more you can benefit from the automation
on document generation side, the status tracking side; and also on the
requirement enforcing side. It sounds first, that you're doing "extra
work" to maintain "some crappy XML as well in addition to coding", but
that's misinterpretation. The design-level information needs to go in
just once; this is where the absolute power in the automation comes
in.
Kalle
Esko Luontola
Corey Haines
previous attempts at code generation has left me skeptical of its
usefulness in applications that I and the people I tend to work with
build.
However, it sounds like I'm not the kind of person you're looking to
convince, so I'm happy to watch this from the sidelines. :)
-Corey
Curtis Cooley
> In that case, I'll step out of the discussion. My experiences with
> previous attempts at code generation has left me skeptical of its
> usefulness in applications that I and the people I tend to work with
> build.
>
> However, it sounds like I'm not the kind of person you're looking to
> convince, so I'm happy to watch this from the sidelines. :)
>
Whenever this topic comes up, either from Kalle or someone else, I
think of an old Bill Nye The Science Guy episode where he says,
"extraordinary claims require extraordinary evidence."
I think about cold fusion and faster than light neutrinos. The cold
fusion "scientists" claimed to have done it, but never published
requisite evidence for other scientist to be able to repeat the
experiment. The faster than light neutrino folks published everything
and received sufficient feedback to restructure the experiment, which
again had neutrinos arriving faster than they should have.
--
Curtis Cooley
curtis...@gmail.com
blog:http://ponderingobjectorienteddesign.blogspot.com
===============
Leadership is a potent combination of strategy and character. But if
you must be without one, be without the strategy.
-- H. Norman Schwarzkopf
George Dinwiddie
On 11/26/11 2:47 AM, Kalle Launiala wrote:
> The design structure is described in meta-model; that is in this
> methodology XML-schema based.
And this is, therefore, a type of source code.
> Template-generators use the pure design level information to
> structurize the program/code. This is of course 1:1 match of the
> design. It's not one-time-shot but continous part of the process.
And this is a type of compilation.
> Templates are coder-project-made (although great reusability within
> teams/community/ecosystem can be achieved), so there is no compromise
> of adjusting your code to someone else's. Templates are really fast to
> make, yet they keep the code simpler to understand than basing on
> traditional object-oriented approach of reusability.
And the templates are similar to the code you might write as part of a
compiler.
Wrapping another layer around everything and changing the names does not
change the fundamental process.
Kalle Launiala
On the process side exactly that; spot-on I'd say. This is exactly the
same process, that has always been there. I've tried to say that this
is all familiar to everyone in the forum, you helped me a lot
underlining that.
If the full stack of software development control presented below
sounds "too big" one can always focus on the last video's
demonstration how we can benefit hugely on the application level
alone...
Now we can focus on the first part, where the difference happens; "a
type of source code". Because at some point we're on so much higher
level of an abstraction than the normal UML design-level, that I
wouldn't be calling that a source code at all.
Here's a visualization draft where we connect pure information from
specificiation level and carry it down to the design level and to the
implementation level:
http://abstractiondev.wordpress.com/2011/09/27/measuring-user-experience-complexit/
Happens exactly like you said in the process. The trick that we can do
this (and actually you can do this as well, it's not a rocket science)
that we can "alter our compilers" in a controllable fashion. Each
abstraction is so small a domain-speficific-language (DSL) that anyone
understands what it does and it's completely open by every aspect. It
can be completely pure and simple, because it can rely on other
abstractions in a modular fashion to do their job; not a single
monolithic-one to carry out really heavy stack.
Here's a video (the part 2 that does the actual modification for
adding CheckBox to the model) of how fast it is to maintain the model:
http://www.youtube.com/playlist?list=PL08AAE51785CF1056
I'll be adding more creation/modification videos relatively soon as
I'm presenting this to general development audience for one of our
local developer communities in two weeks.
Kalle
Kalle Launiala
I hear you; the basic rule of science also applies. The theory cannot
argue with repeatable and solid experimental evidence.
The claim is that in current software industry everything can be
automated within completely controlled fashion.
The evidence is the key here. The corner stone of the evidence is
presented here:
https://abstractiondev.wordpress.com/absolute-proof/
Now that evidence holds "recursively" as well; the normal software
production already accepts compilers (C#, C++, Java, C, Algol, Prolog,
you-name-it), so not everything has to be written in assembler form.
We can automate a bit above to reach pure design level, then automate
again (within the same changeset), and again...
Now that's where it all builds up to.
The "practical side" is that we can achieve this with XML-Schemas and
with low-learning-curve template-generators (web-technologies have
used template-replacement for a long time already and that's so
devilishly simple that we've ended up with all kinds of good and not-
so-good web applications out there).
Current threads for George are focusing in the process; Esko's (and I
believe Corey as well) focus is on the side of code generation being
as easy to do as I claim.
I'll address these issues on those threads.
Kalle
On 27 marras, 18:45, Curtis Cooley <curtis.coo...@gmail.com> wrote:
> On Sat, Nov 26, 2011 at 10:40 AM, Corey Haines <coreyhai...@gmail.com> wrote:
> > In that case, I'll step out of the discussion. My experiences with
> > previous attempts at code generation has left me skeptical of its
> > usefulness in applications that I and the people I tend to work with
> > build.
>
> > However, it sounds like I'm not the kind of person you're looking to
> > convince, so I'm happy to watch this from the sidelines. :)
>
> Whenever this topic comes up, either from Kalle or someone else, I
> think of an old Bill Nye The Science Guy episode where he says,
> "extraordinary claims require extraordinary evidence."
>
> I think about cold fusion and faster than light neutrinos. The cold
> fusion "scientists" claimed to have done it, but never published
> requisite evidence for other scientist to be able to repeat the
> experiment. The faster than light neutrino folks published everything
> and received sufficient feedback to restructure the experiment, which
> again had neutrinos arriving faster than they should have.
> --
> Curtis Cooley
Kalle Launiala
The technology we use is based on template-based generators. The same
that web-development has been accusomed to pretty much "standard"; to
have html generated "on-the-fly" based on back-end object model
structure.
I think you're right on having "generic code" by orders of magnitude
slower to produce than hand-written. This is exactly why traditional
class-libraries or even base-class structures take much longer to do
than "just write the code and get over with".
Now template-based generators are really fast to make; it's mostly
copy-paste your existing code to very slim generator and replace the
replacements.
The video for modification is really small now; I'm in process of
making better example of abstracting "anything" from scracth. But the
"Part 2" of the videos shows how to change the model and alter the
generator to reflect the change:
http://www.youtube.com/playlist?list=PL08AAE51785CF1056
Once you give responsibility for that boilerplate to automation-
generator, you start saving tremendous amounts of time when you do
need to maintain it. Reusability underlines this really well, as
without binary constraints, the reusability factor jumps skyhigh.
Kalle
On 26 marras, 16:05, Esko Luontola <esko.luont...@gmail.com> wrote:
> I'm sceptical of the efficiency of writing a code generator to produce your
> code, versus writing the code itself, because in my experience writing such
> generic code (i.e. using reflection or code generation) is an order of
> magnitude slower and harder than writing non-generic code which does the
> same thing. That's why I use it only when some boilerplate needs to be
> repeated many times and no other way of removing the duplication is
> possible.
>
> As an example of where I've used code generation, is taking as input a Java
> interface [1] and generating a bunch of classes based on it [2] which are
> then used in message passing (in this project I can't use e.g. Scala, so I
> need to survive with Java).
> [1]https://github.com/orfjackal/jumi/blob/master/jumi-actors-maven-plugi...
> [2]https://github.com/orfjackal/jumi/tree/master/jumi-actors-maven-plugi...
>
> Writing the above mentioned boilerplate classes by hand for one interface
> takes about 15 minutes. If you look at the "Let's Code Jumi" screencasts athttp://www.orfjackal.net/lets-code#jumiyou will see that doing the same
Dave Rooney
Kalle Launiala
You somewhat managed to miss the entire point.
Of course messaging is critical in anything that's network related.
However logically there is nothing interesting in messaging from the
application point-of-view.
I claimed that everything can be automated without any compromises
(possible to reach absolutes on minimal amount of possible information
and maximum amount of refined output).
Same holds for the network stack entirely; application/service/
solution-wise is uninteresting how the information traverses between
application logic. Only thing that even close resembles any interest
is whether the call is asyncrhonous or synchronous or in some data
streaming, perhaps if the traffic is lossless or accept loss.
Of course someone still has to make the automation module for certain
network stack features, but its reusability being close to 100% it's
hardly an issue. Also the network stack can later be optimized further
without having to touch the application code at all (just update the
module and rebuild).
In our demonstrations (downloadable) we already demonstrate automated
network level where three parallel communication channels are created
for different server-client combinations. None of the application
layers really care which protocol/serialization scenario is used.
Only thing that automations certainly cannot do alone is the
information architecture; thus mapping the real world information
against the computer processed data.
Kalle
Kalle Launiala
communication as an independent module within this week.
I am having a meeting with researcher focusing particularly on IP-
level communication optimization. Will be interesting to see standard
application reaching down to IP-level of network stack with its full
knowledge of what data exactly is required on the other end of
application level.
Why on earth do we need a SOAP stack on network end where both can be
using same abstraction-automation module to negotiate much more
compact and efficient protocol (regardless of the platform or language
they are built with).
Kalle
Dave Rooney
On 2011-11-28, at 12:42 PM, Kalle Launiala wrote:
> Dave,
>
> You somewhat managed to miss the entire point.
Yes, I suppose I did.
When you have something that explains your point much, much more clearly and with dozens of real-life applications, let me know.
Dave...
Andreas Leidig
really impressive who (including) and how many are still reading and communicating with Kalle about his ideas.
@Kalle:
I think YOU are the one who is missing the point. If you have a great idea and are not able to show it to people who are really interested, their reaction will be sceptical if not negative.
Why don't you just show your code? - If it is great but private property then it's useless for us. Your refusion makes me think that you are just talking. I can neither prove you wrong nor can I learn from your experience.
I propose you stop wasting my and probably other's time.
Regards,
Andreas
P.S.: If there is anybody on this list still interested in Kalle's point please let us know so the discussion can continue.
Am 28.11.2011 um 18:48 schrieb Dave Rooney:
> Kalle,
> On 2011-11-28, at 12:42 PM, Kalle Launiala wrote:
>
>> Dave,
>>
>> You somewhat managed to miss the entire point.
>
> Yes, I suppose I did.
>
> When you have something that explains your point much, much more clearly and with dozens of real-life applications, let me know.
>
> Dave...
>
<snip/>
RonJeffries
Ron Jeffries
Kalle Launiala
Do you mean code that is available freely in git repositories and
CodePlex downloads?
CodePlex downloads have been available all the time at:
http://abstraction.codeplex.com/releases
The git repository works as well, but this hasn't been publicly listed
as there are some more documentation that I have to make to make the
modules to use. It requires building and running the
abstractionbuilder (afterwards running the templates at least once):
git clone git://github.com/abstractiondev/Demo.git
cd Demo
gitupdateproject.cmd
(You need the last one to update the submodules)
I am really confused by your comments. Everything is ready-to-use and
make-yourself-your-own on Visual Studio environment, MonoDevelop works
as well, but requires bit more tweaking.
The general idea works though.
All this information is I think well enough structured on the blog
site (that links to downloads section as well).
Kalle
Robert Hjertmann Christiansen
Kalle Launiala
I start to get the general idea myself as well.
I tried to share with this community a general/universal way of
automating anything in development process.
Not a framework, not a library, not even a tool. Works as-is on Visual
Studio and MonoDevelop (alike features likely can be found in Eclipse
as well, but I wouldn't know as the discussion degenerates immediately
to something quite different).
What a surprise it shares details with other compiler/dsl/code-
generation aspects.
The key difference is (why you can do all the things I claim, without
any compromise):
- The model and the generators can be changed within the same project
where all the manual code also works - in a practical manner in the
same checkin/commit.
I'm a single fellow behind this, and all I ever did on SC forum was to
share this methodology openly (as we do with the blog as well).
It's implicitly open source by design; it must be. Hasn't prevented
attacking my claims for "your private stuff".
I would have explained how it works, but apparently this thread is
filling up with people who "are not interested and nobody else is
interested either".
Kalle
P.S. SC is definitely "off-mainstream" I give you that. Microsoft's
Visual Studio team at least replied to me "Thanks for sharing". Made
my day while this forum didn't.
Kalle Launiala
I guess so.
What I don't understand is why some people here are so eager to join
in any thread and tell that they're not interested and nobody else is
interested either. I'll make my reply to this post be the final in the
thread, if nobody really is interested to learn about this
methodology.
So my version of the discussion:
What a surprise, that the methodology shares details from other common
methodologies.
The one key difference is that it works as-is on mainstream tools
(Visual Studio and MonoDevelop; the same pieces are found likely in
Eclipse as well) and its meta-model is based on XML-standard.
All the people saying that this is "nothing more than MDA" are right,
I'm not arguing that. Just show me the MDA or any other alternative
that works out-of-the-box WITHOUT any external framework, library or
tool and you can change the model and the generators in a practical
fashion within single version control changeset.
This methodology is even fully-open-source because it by design has to
be. I find it amusing to attack me for being "private" on this, when
I've done within my powers to try to demonstrate and explain it as
much as possible.
I'm a single person behind this and all I wanted to do was to share
this with SC community. I know better know not to dare to try it
lightly again.
Kalle
P.S. Microsoft's Visual Studio Forum at least had the nice gesture to
reply to me "Thanks for sharing". That made my day at least for today.
On 28 marras, 20:31, RonJeffries <ronjeffr...@acm.org> wrote:
Bobby Johnson
--
You received this message because you are subscribed to the Google Groups "software_craftsmanship" group.
To post to this group, send email to software_cr...@googlegroups.com.
To unsubscribe from this group, send email to software_craftsma...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/software_craftsmanship?hl=en.
"The explanation requiring the fewest assumptions is most likely to be correct."
- Occam’s Razor
http://en.wikipedia.org/wiki/Occam's_Razor
Kalle Launiala
Usually people don't bash me this much on public, but I understand
your point :-) The chemistry Nobel-prize winner winner this year had
it much worse on this days:
http://www.reuters.com/article/2011/10/05/nobel-chemistry-idUSL5E7L51U620111005
Thanks for those who sent me private messages (there weren't many, but
enough to say that some people are interested). I'll keep it private
with those people.
Here's the link for the neutral university assesment report of this
very methodology (yes, this one, not a generic MDA):
http://abstractiondev.files.wordpress.com/2011/11/add-report.pdf
The devilish breakthrough is the one that doesn't seem any different
from the side of the current developers.
I guess I made my presentation in the SC, thanks for the amusement for
my part as well.
Kalle
On 29 marras, 03:33, Bobby Johnson <bobby.john...@gmail.com> wrote:
> if you read this as a 3 act play with the role of Kalle being played by
> a fascinating markov chain implementation it becomes far more
> entertaining...
>
Kalle Launiala
up into Visual Studio's T4 Team's Official Blog:
http://blogs.msdn.com/b/t4/archive/2011/11/30/some-nice-new-getting-started-with-t4-videos.aspx
I feel like the Dolphins in the "Hitchikers Guide to The Galaxy". So
Long, and Thanks for All the Fish.
Kalle
On 29 marras, 08:27, Kalle Launiala <kalle.launi...@gmail.com> wrote:
> Bobby,
>
> Usually people don't bash me this much on public, but I understand
> your point :-) The chemistry Nobel-prize winner winner this year had
> it much worse on this days:
>
> http://www.reuters.com/article/2011/10/05/nobel-chemistry-idUSL5E7L51...