Prev: Interactive web-based graphs for iPads?
Next: FAQ Topic - How can I disable the back button in a web browser? (2010-06-17)
From: Sherm Pendley on 17 Jul 2010 14:59
Jeremy J Starcher <r3jjs(a)yahoo.com> writes:

> I can't swear to it ... but it seems like Turbo Pascal for the CP/M
> machines had a 'file' drop down in the left corner

Don't know about the CP/M version, but Turbo Pascal for DOS certainly
had the kind of character-based "gui" you're referring to. And yes, it
had all the "usual" menus - File and Edit at the left, and Help on the
right.

sherm--

--
Sherm Pendley <www.shermpendley.com>
<www.camelbones.org>
Cocoa Developer
From: David Mark on 17 Jul 2010 15:32
On Jul 16, 1:03 pm, Kenneth Tilton <kentil...(a)gmail.com> wrote:

> When I do have clients they ask me to
> check out different libraries they themselves have come across, and one
> explicitly encouraged me to use a /big/ library like Dojo instead of a
> small one like jQuery so I would not be re-inventing the wheel.

You've certainly got fools for clients. :) In the case of Dojo, the
"wheels" they invented are non-starters (think square). That's why
they are constantly trying to re-invent themselves. Like Prototype,
I've heard they have plans to scrap most of what has come before and
build a new "Dojo" from the ground up. Which raises the question of
what is a "Dojo" or a "Prototype"? AFAICT, they are simply brand
names that are largely synonymous with futility.

>
> Tilton's Law: Solve the right problem.

Oh brother.

> In this case, if the problem is
> that a JS library has a bug, the solution is to fix the bug, not burn
> the library and have every programmer who wants to put up a web page
> spend five years learning HTML and CSS and browser variability.

There are so many things wrong with that, I don't know where to
start. For one, JS is intended and best-used for enhancing HTML and
CSS. It's not a substitute. And "browser variability" is no big deal
these days (provided authors do not attempt to solve every conceivable
problem for everybody). Yes, the GP library authors fail to get this
basic concept, so they perpetually make browser cross-scripting look
much harder than it is. It's not the browsers; it's *them*. If they
weren't trying to do way more than is needed for any given site or
application (i.e. design a monolithic do-everything JS library), they
wouldn't have so many problems. Can't fix their mindsets, so the only
alternative is to warn beginners to avoid their ill-conceived
products.

Furthermore, I've done more charity work in this area than anybody and
it is typically unappreciated by needy library authors who very
quickly grow confused and irritable and dismiss suggestions as less
than constructive. Then, a year or two later, something clicks and
they announce to the world that *they* have figured it out (see John
Resig and the case of jQuery's UA sniffing). And in the interim,
thousands more blissfully download defective versions, polluting the
Web with garbage code that somebody will eventually have to clean up.

>
> That's actually rather obvious, so it's fun seeing the alpha males
> around this NG forever arguing against it.

Arguing against what?

> Using a little FUD to keep
> those billing rates up, are we? Best of luck, these are tough times.
>

FUD? That's what the displaced Java developers behind Dojo were
saying back around 2007. They didn't listen to their critics, didn't
learn from their mistakes and just look at them today (going back to
the drawing board). I have clients who tried Dojo at some point and
I've heard the horror stories. I'm sure most of them wish they had
never listened to parrots like you. FUD, squawk! Re-inventing the
wheel! Write from scratch; write from scratch; assembly language;
snark; ivory tower; tweet! Use Dojo. Who's a pretty boy? :)

And as for high billing rates, those are a welcome side effect of mass
ignorance and impotence in this area. The fewer competent JS
developers, the better. ;)
From: Scott Sauyet on 17 Jul 2010 16:04
David Mark wrote:
> Kenneth Tilton wrote:
>> Using a little FUD to keep
>> those billing rates up, are we? Best of luck, these are tough times.
>
> FUD?  That's what the displaced Java developers behind Dojo were
> saying back around 2007.

Is that true, Dojo was written by people who thought in Java? It
would explain a lot.

-- Scott
From: David Mark on 17 Jul 2010 16:36
On Jul 17, 4:04 pm, Scott Sauyet <scott.sau...(a)gmail.com> wrote:
> David Mark wrote:
> > Kenneth Tilton wrote:
> >> Using a little FUD to keep
> >> those billing rates up, are we? Best of luck, these are tough times.
>
> > FUD?  That's what the displaced Java developers behind Dojo were
> > saying back around 2007.
>
> Is that true, Dojo was written by people who thought in Java?  It
> would explain a lot.
>

Yep and it does indeed. Avoid like the plague. :)

From: Garrett Smith on 17 Jul 2010 21:41
On 2010-07-17 08:59 AM, Stefan Weiss wrote:
> On 17/07/10 09:03, Garrett Smith wrote:
>> On 2010-07-16 07:40 AM, Richard Cornford wrote:
>>> Stefan Weiss wrote:
>>>> One more thing. I am a JS developer (among other things), and I
>>>> am able to create these things if I want to. Other people,
>>>> including many web designers
>>>
>>> Does "web designers" mean (effectively) graphical designers working
>>> on/producing websites? (as distinct from 'web developers' responsible
>>> for code/application architecture design, UI interaction design,
>>> database design (in relation to websites), server configuration design,
>>> and so on.)
>>>
>>>> and amateur bloggers, webmasters, etc, don't have that
>>>> experience.
>>>
>>> No, they (mostly) do not. That is not an unexpected situation as
>>> realistically most people do not have experience in most (more than
>>> slightly) specialised things. Generally that is not a problem as
>>> (effectively) we sell our own specialised experience in order to
>>> purchase the experience (or products of the experience) we need/want of
>>> others. And faced with a lack of experience/knowledge in an area most
>>> people are happier (and probably better off) purchasing that experience
>>> than trying to do it themselves.
>>>
>>> Almost nobody, for example, would contemplate making their own china,
>>> even though it would not be at all physically difficult to do so (at
>>> least using available fabrication techniques that do not include
>>> throwing posts on a potter's wheel).
>>
>> There are many interesting things to do in the world and many of them
>> are also dangerous.
>
> The (snipped) story about the dangers of home-made china, while
> interesting, is not a very good analogy to what amateurs are doing on
> the web. At the very least, the analogy grossly exaggerates the
> consequences: build your own china, and people can die from lead
> poisoning; use a substandard script you copied from somewhere, and your
> homepage could break for a certain percentage of visitors.
>
> I realize that this is going to be a minority opinion in a technically
> oriented group such as this, but I still think that everybody - even the
> most clueless newcomers - should be allowed, and even encouraged, to
> play on the web any way they like. Let them use huge animated GIFs,
> background sounds,<blink> tags, UA sniffing, jQuery or any other JS
> library, let them proclaim that "this site is best viewed with
> {browser}", etc. Anything to get them interested and give them a sense
> of achievement. Some will become fascinated enough that they'll
> eventually learn how to do it right. Other's will not.
>
> I'm firmly convinced that the low barrier of entry, combined with the
> openness of the basic technologies is what allowed the Web to become
> widely accepted and grow to what we see today. Had it been necessary to
> hire a professional to build a homepage, none of this would have happened.
>
> The low barrier of entry has its downsides, of course. Fred (to use a
> random name) looks at the source code of a document, decides to try this
> out for himself, writes 'alert("Hello, world")', and is delighted with
> the result. Three days later Fred's applying for a job as a JavaScript
> developer. At the time, there isn't any useful certification process or
> formal training which can be used to decide if Fred really knows what
> he's talking about. I know that some companies use certifications to
> screen applicants, but that's a very bad practice, IMO. Many of the most
> talented people I've met are self trained. I've also seen some of those
> certifications and heard some enlightening anecdotes about how to get
> them in a few days, provided you know the right people or are willing to
> invest some cash. The technology is too new and moves too fast for these
> types of indicators to work. This leaves us with a gazillion
> web/software "developers" and even so-called "engineers", and no
> objective way to tell what that means. If he's got a nice homepage, and
> the interviewer doesn't know the right questions to ask, Fred may even
> get the job. And maybe he'll even grow into it, who knows.
>

Lack of skill is a fundamental cause of problems with the web.
Hallvord's blog covers many such examples.

I have interviewed at two design firms where I was brouht into a sort of
"demo" meeting room where I was asked to pull some URIs of things I've
worked on on the big monitor. "What a stupid idea," I thought, while
obliging their requests, showing various widgets I've made and sites
that I have worked on; including those whose code is so embarrassingly
bad that I won't even mention them here, yet the clients were impressed
with that awful code. They seem to have observed those works as
resembling something of competence, they did not look at any of the
source code to see that they were a total disaster, which is what I do,
and had done prior to regretfully taking one of the admittedly well-paid
jobs.

> These are not the people I'm competing with. As far as I'm concerned,
> they're playing a completely different game. I don't offer "scripting"
> or "web design" or "programming". I'm hired for my experience, past
> successful projects, my network of colleagues with different special
> areas, the infrastructure I can supply, and my ability to talk to both
> customers and colleages in a friendly and professional manner. But the
> main difference to people like Fred is experience. I wrote my first
> program at 13. In the past 11 years, after dropping out of university, I
> have worked with many different OSs, on different hardware
> architectures, in very different organizational environments, used
> different languages (computer and natural), different frameworks and
> paradigms, alone or in teams, client side and server side, etc. This
> gives me a perspective that newcomers cannot possibly have, and that
> experience goes into my hourly rate (the project mentioned earlier
> notwithstanding). After hiring 2-3 Freds, customers usually want to "do
> it right this time" and hire an expert.
>
>>> There is much to be said for understanding the consequences of
>>> actions, particularly in terms of avoiding the bad ones.
>
> Absolutely.

While that is true, if the understanding is actually a misperception of
consequences, then a false principle has been created and will be
misapplied in the future.

What it really boils down to is knowledge.

>
>>> A different moral dilemma might apply to them. Granted, if you are
>>> talking about a complete armature doing what they like to please
>>> themselves then any consequences (good or bad) fall only on them. But as
>>> soon as someone is acting in the role of 'client' is involved the
>>> consequences of design decisions are no longer local.
>
> Everybody starts at square one. I'm not particularly proud of the work I
> did 12 years ago. Looking back at that time, I certainly wasn't
> qualified for some of the tasks I was given, but that was at the height
> of the dot-com bubble, and companies were desperate to hire just about
> anybody who knew what a computer looked like. So I got to work on real
> projects. I don't see any other way for newcomers to get hands-on
> experience. Of course, they should be honest and not inflate their own
> abilities, or call themselves "gurus" or "ninjas" after a year or two.
> Or ever ;-)
>

These terms, "ninja" and "guru", are applicable to acts of mysticism.
Individuals employing what Richard likes to term "mystical incantations"
don't really understand what they are doing but get a result and may
apply a post hoc thesis which may or may not be correct. To the observer
who understands nothing, the outcome of the result cannot be explained
and so the programmer providing not providing an explanation of the
outcome is irrelevant.

A consequence of producing an inexplicable result is that those who
create such results can be named as "ninja" or "guru" -- entirely
meaningless terms that come with a negative connotation to a very
limited number of individuals (myself included).

>> I was interviewed about two years ago by a senior front end engineer
>> with 15 years experience. The first and only technical question was to
>> build a rich text editor.
>
> Write a rich text editor from scratch? Did he want that with or without
> a flight simulator plugin? What an odd thing to ask as a demonstration
> from a job applicant.
>
> (quote reordered)
>> Experience without knowledge isn't much use.
> ...
>> There is no substitute for knowledge [Deming].
>
> I respectfully disagree (with you and Prof. Deming). Knowledge can be
> acquired in a short time, if necessary, but experience can't. Deming
> died before information systems like the web made it trivially easy to
> retrieve required facts from online references. For example, I often
> don't remember the exact name or order of arguments for a method, but I
> know from experience that such a method exists, and that I can look it
> up when I need it. If I can't find the required information, I know
> (again, from experience) where I can ask questions and how to formulate
> them. There's a German expression which unfortunately can't be directly
> translated into English: "Fachidiot". The word describes a person who is
> an expert in a limited area, but ignorant about everything outside his
> field of expertise. Such a person would have a lot of knowledge about
> his area, but _experience_ goes further than that. It implies that
> you've seen things fail when you thought that was "impossible", it
> implies that you've learned how to deal with difficult co-workers, and
> it also implies that you can judge the consequences of your
> implementation on systems outside of your own area. For example, from a
> JS point of view, that would include issues relating to server-side
> proxies, security, network problems, version control, and even
> psychology: an experienced person will have heard about ways to improve
> the user perception of a piece of software, and the best way to
> formulate error messages. A knowledgable newcomer will still have to
> learn these things.
>
>
That newcomer is missing knowledge.

That newcomer may continue about the way he has done things all along
with varying degrees of success. He may do so for many years and may
gain experience in doing these things without being able to explain
them. This describes an individual who is experienced but lacks knowledge.

The difference between an individual who can explain something vs one
who cannot explain comes down to knowledge and understanding. As was
demonstrated in my interview with the senior front end engineer,
experience was not a substitute for knowledge.

An experienced developer may, for example, formulate a solution which
works based on trying to replicate what worked in the past and may enjoy
varying degrees of success with this.

An example of this is seen in the opening lines to Sencha:

| window.undefined = window.undefined;

Another is in dojo:
dojo.isArray = function(it) {
return it&&(it instanceof Array||typeof it=="array");
};

The authors of Ext-js and dojo may have more experience than I do. What
does that say when they continue to publish code that shows a lack of
knowledge?

Code may be obscurely written, have an unrecognized flaw that applies
exclusively to the situation (perhaps only in an uncommon case), provide
a workaround to something irrelevant, contain misleading or obsolete
comments, be mostly irrelevant, and can be full of bugs that exist in
code paths that are untested but never reached. The same code may also
fulfill the requirements.

The author is of such code may be overlooking important considerations
of code quality including clarity, efficiency, extensibility, etc.

Sufficient criteria for the assessment of front end skill has not been
formally established. You, I, and Cornford all have seem to have
expressed that to some degree.

A precursor to making assessments of front end skill is the ability to
make assessments of the quality of front end code. For that, I have been
working on the code guidelines document.

<http://jibbering.com/faq/notes/code-guidelines/>

This document can be improved and I would like more feedback on it.

One thing that I have wanted to change is the "Avoid modifying objects
you don't own. ". While that is a nice trite phrase, it doesn't cover
the aspects of defining cohesive objects.

"Define cohesive objects" is better but that does not imply that doing
the opposite is wrong.

"Avoid interdependencies" is better and expounding on host object in
that section is still appropriate, however some interdependencies make
sense, so I can't say I'm satisfied with that, either.
--
Garrett
First  |  Prev  |  Next  |  Last
Pages: 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32
Prev: Interactive web-based graphs for iPads?
Next: FAQ Topic - How can I disable the back button in a web browser? (2010-06-17)