Slashdot Mirror

"The dirty little secret that Microsoft has been hiding all these years is that piracy was GOOD for them in creating their monopoly. Now that they have a monopoly, however, they believe the illegal copying does them no good, so they are trying to stop it."

"Although about three million computers get sold every year in China, people don't pay for the software. Someday they will, though. And as long as they're going to steal it, we want them to steal ours. They'll get sort of addicted, and then we'll somehow figure out how to collect sometime in the next decade."

I agree with you somewhat, but in true Slashdot fashion, none of us monkeys can agree with each other completely... What fun would that be? One comment max, on every post!

Anyhow, ideally a wiki should have every contributor be both contributing AND editting.

But in theory, nobody will, they'll just throw their points together like the Portland Pattern Repository (http://c2.com/cgi/wiki) and have everything looking like crap.

Sigh, too bad. Although I'd love to be proved wrong!

If you are at all familiar with XP, then you've probably heard YAGNI. XP is all about option theory, because it is expensive to write good software, so you need to keep your options open so you don't through money away.

You don't have that problem in system administration because so many of the tools are so cheap. And YOU ARE GOING TO NEED IT. We've seen the YAGNI approach to home firewalls and spyware checkers and anti-virus. System Administration is about having it all. So many great tools out there and not enough cuban coffee to try them all out.

I'm sure there are some big administration projects that would benefit from XP, but I don't have any experience with them. It seems the agile practices are best applied to development work.

That is really stretching the definitions of both magic and science beyond the breaking point.

In case anybody is interested, here are some suggestions for making a more relational-friendly alternative to XML, Here is a wiki topic.

Another potential problem is that existing RDBMS tend to be strong-typed. However, "dynamic relational" is not out of the question. Just because current RDBMS are strong-typed and have "static schemas" does not mean that is the only way to do it. There is a distinction between limits of implementations and limits of relational theory.

It is possible to replay the execution of programs that communicate with the outside world, rather than just in an isolated virtual machine: you have to log nondeterministic events. See http://www.erights.org/elang/concurrency/determini sm/overview.html.

The first language I know of that supported replay is the Abundance database language, back in 1986. Also see http://c2.com/cgi/wiki?ReversibleProgrammingLangua ge.

People who use design patterns effectively will write more maintainable code.

Yawn... Insert obligatory response to someone touting the utility of design patterns here.

People who use design patterns effectively will write more maintainable code.

Yawn... Insert obligatory response to someone touting the utility of design patterns here.

It appears you want a wiki that discusses the same topics you find discussed often on Slashdot. If you like Slashdot, and you like Wikipedia, then you might also enjoy the patterns wiki, the meatball wiki, or the infoanarchy wiki.

See here for example. And there are a few good arguments against threads entirely (one of them being Linux's ultra-lite fork() implementation, which is of course not portable).

That said, AFAICT the only reason I can see that (AFAIK) no portable native-thread Ruby module has yet been standardised on is that Matz doesn't like the idea.

You can target that too.

Before you want to call me retarded, have the guts to put your name behind your words, otherwise shut-up.

Perl and ruby are very similar, if you know one you can easily pick up the other.

No, they're actually not similar at all, and if you were familiar with ruby you would have a bit of a clue regarding this. It's closer to smalltalk than Perl, really.

Also: "EMACS is a nice operating system, it just lacks a text editor" (Emacs Stands For...)

True enough, however, simple data all too often becomes complex data. That's why it's a good thing to be "extensible".

Delimited can also be extensible if there is a field definition header. The problem is that there is no standard.

Wiki notes on improved delimited format suggestions.

Thank you for succinctly illustrating why we need licenses for Software Engineers. Let's take a closer look:

Dear god no, mixed case leads to gobs of errors from nothing more than incorrect case.

This is a style issue. Everyone has their own idea of what is (or is not) most readable. What is more important, however, is that the chosen style is applied consistently.

What this also tells me is that you aren't particularly thorough and are prone to making assumptions, which are really bad traits for a developer. You should work on that.

Next is this BS about self-documenting code. Code is not meant to be self documenting.

Perhaps you need to find out what self documenting code is. It is about making code obvious and readable, so that you don't need to *gasp* COMMENT code everywhere. And it does consider notions of scoping and choosing sensible variable names within the context.

Write the most efficient function you can

Write the simplest function you can. It is always the easiest to get right, and the easiest to maintain. If you have a performance issue, chose a better algorithm first, and only then move on to improving code effeciency. Otherwise you end up with a huge and hard-to-maintain code base, that requires lots of *gasp* COMMENTS so that you can understand what's going on, because "efficient code" tends to be less readable.

code is not a spoken language and is a poor medium to use to express messages between people who speak one

Code is in fact an excellent language for communicating accurately at a low level. Spoken language is often poor at this level, but is excellent for conceptual communication. Thus a comment should describe in spoken language the algorithm that is implemented, but the implementation should be (largely) self documenting and easy to follow (assuming you are familiar with the algorithm).

By_using_variable_nms_that_dnt_lk_like_this 40 times in 6 lines of code you will save enough time writing those 6 lines that you can add a nice comment that says # vnameshort is used ...

But there is trade-off between the time you take to write your function, and the time it will take many different maintainers in the future to figure out what it does. Trying to remember the meaning of half dozen short variable names while you interpret someone else's code is not a recipe for efficiency.

Meaningful variable names don't have to be long; in fact the best ones are short, accurate and unambiguous.

Believe it or not, I do not want to read your 100,000 lines of source to make one change. I want to be able to look at the main routine and b-line right from there to the portion of the code I need using the commented function calls

This is not surprising. It is what most developers want to do. Dive right in and fiddle. Without knowing what's going on, of course: you have no idea what effect your change is going to have on the other 99,800 lines of code.

A friend of mine's engineering lackey was having problems with a particular scenario in some software he was tasked with implementing.

"""The background to understand his problem. This is a sealed bid auction. Contingency bidding means that you only win 1 auction if you won all auctions in your Contingency Bid."""

I noted that it looked a lot like Condorcet Voting, which is not something you'd learn (generally) in a strict CS/Math/Eng school. Not much of a point, but in general, beware of over-specialization. Specialization is for Insects.

--Robert

It's possible to adapt some development practices to operations, or develop practices specific to operations, but not be a "methodology".

Systems Administration Practices on the XP wiki.

First, there is the possibility that Apple screwed up the shuffling algorithm -- although not entirely likely. If you ask an introductory programmer to write some code to shuffle an array, you'll most likely get something like this:

for i in range(array_length):
j = random() % array_length
temp = array[i]
array[i] = array[j]
array[j] = temp

This code does NOT produce all permutations with equal probability! Instead, you must use the following code:

for i in range(array_length):
j = i + (random() % (array_length - i))
temp = array[i]
array[i] = array[j]
array[j] = temp
}

This was cribbed from c2 -- see the full article text here for a more informative discussion.

Second, I see a lot of people saying "I have a 20GB iPod -- and I swear sometimes it just NEVER plays this one song." Okay, let's assume that a 20GB iPod holds 5000 mp3 files. What's the probability that you play 5000 songs in shuffle mode, and never hear a particular song?

It's the probability that 5000 times in a row, you hear some other song -- that is, one of the 4999 other songs. Calculating, we get:

(4999/5000)^5000 = 0.3678.

So we have a 36% probability of this happening -- which is not a negligible amount! This will further be compounded by two things: First, you have no way of recalling exactly it has been since you heard a particular song -- if your favorite song was played 1000 songs earlier, it probably feels like 2000. If it feels like 2000, it's probably 4000. Because it's a favorite song, your mind will exaggerate the amount. It's like if you crave nicotine, it can feel like days since you've had a cigarette when it's only been hours. Second, you probably have a lot of songs you would call a "favorite" -- with each having a 36% chance of not being played over the course of 5000 plays, your mind will probably register that at least one of them is "feeling neglected."

Probability is a strange and beautiful thing. Don't expect your average audiophile to understand it. (And I'm not claiming to understand it either, beyond a very cursory level.)

- shadowmatter

Knuth was quoting C.A.R. Hoare and in "The Errors of TeX" he at least gives proper attribution.

Yes, I stand corrected, although I guess Knuth popularized the saying a bit more.

See http://c2.com/cgi/wiki?PrematureOptimization for more details and other famous optimization quotes.

Maybe you you are a tetrachromat. As in: A human with 4 distinct color receptors on his/her retina.
Most humans are trichromats. Most (if not all) tetrachromats are females.

Look here: TetraChromat

ps. I had a very hard time telling those 2 colors apart, but could. I doubt I would have noticed if I
hadnt known beforehand.

Shut the fuck up Ron, you fucking ugly motherfucker. Or I'll break your fucking face.

Not only that, but the open content license also allows Google to profit from providing premium access (read: low-latency) to their own instance of the content.

Not only that, but from Google's point-of-view Wikipedia provides the benifits of Yahoo's original function and the Open Directory Project. That is, the community's openness actually seems to provide insentive to edit and add to the the content, while the collective wiki gardening also removes wrong, out-of-date, or very low quality articles and spam from the system. Thus Wikis - and Wikipedia in particular - generally provide high quality links that search engines can use to target and/or refine their search bots. This helps them with searching, targeting adwords, anti-spam filtering in Gmail, among others. That's why spammers try vandalizing them so much. Given Google's lead among their peers with document analysis algorithms, they have a high incentive to support wikis like Wikipedia.

Not only that, but the open content license also allows Google to profit from providing premium access (read: low-latency) to their own instance of the content.

Not only that, but from Google's point-of-view Wikipedia provides the benifits of Yahoo's original function and the Open Directory Project. That is, the community's openness actually seems to provide insentive to edit and add to the the content, while the collective wiki gardening also removes wrong, out-of-date, or very low quality articles and spam from the system. Thus Wikis - and Wikipedia in particular - generally provide high quality links that search engines can use to target and/or refine their search bots. This helps them with searching, targeting adwords, anti-spam filtering in Gmail, among others. That's why spammers try vandalizing them so much. Given Google's lead among their peers with document analysis algorithms, they have a high incentive to support wikis like Wikipedia.

Not only that, but the open content license also allows Google to profit from providing premium access (read: low-latency) to their own instance of the content.

Not only that, but from Google's point-of-view Wikipedia provides the benifits of Yahoo's original function and the Open Directory Project. That is, the community's openness actually seems to provide insentive to edit and add to the the content, while the collective wiki gardening also removes wrong, out-of-date, or very low quality articles and spam from the system. Thus Wikis - and Wikipedia in particular - generally provide high quality links that search engines can use to target and/or refine their search bots. This helps them with searching, targeting adwords, anti-spam filtering in Gmail, among others. That's why spammers try vandalizing them so much. Given Google's lead among their peers with document analysis algorithms, they have a high incentive to support wikis like Wikipedia.

Those are all very good books. You'll want them. And especially take note of Peopleware, it's often overlooked.

But there are two good ones missing:

• Rapid Development
  by Steve McConnell
• Agile Software Development with SCRUM
  by Ken Schwaber, Mike Beedle

I'd say you'd definitely want to read Rapid Devlopment before Code Complete. And the Scrum book will save you.

http://c2.com/cgi/wiki?AlexeyPajitnov shows that he's finally getting royalties and is employed by Microsoft Research.

Absolutely, its called An Acceptable Way Of Failing.

Skipping the hi-tech "viab" crap that Sterling focuses on, the appeal here is a return to the less planned, less structured, and more organic process such as the mechanism that grows free software. Wabi-sabi is the formal word for this informal approach and it's been around for centuries. It goes a long way to explain what technology is now discovering.

Here's the Wikipedia link.

It made me chuckle every time the test failed. I stopped chuckling when my boss's boss came in to ask what progress I was making. As soon as his back was turned, I changed the failure string to something more... neutral.

Maybe it's a good reason for the Extreme Programming practice of pair programming - to prevent you from doing something "funny" that will get you in trouble.

We had a similar debate on c2 wiki.

It seems that FTP, email, web services, and/or databases can be used instead. I am not sure we need Yet Another data-sharing mechanism/protocol unless it offers something truely unique.

You might not realize it, but that example is actually agreeing with your parent. A subclass that does that is breaking the substituion principle.

Cairo or Longhorn, same thing. (I wish people would (a) stop overloading "code names", (b) telling everyone what their new thingy is called now until they figure out the real name.)

The time you want to limit the character set used in a password is when the password goes into a web form.

Ok, so by doing that you're reducing the chances of receiving input that can be used to inject valid SQL. But there are some other things to consider too.

• You're making an assumption in one layer about a layer beneath it. This is coupling and when designing software it is generally best to avoid it if possible - and it is certainly possible in this case.
• Although true that you are reducing the likelihood of SQL injection, what about injection into other text-based languages: e.g. XML, HTML, TCL, etc. I've seen injection vulnerabilities in all of these. Are you going to change all input validation if you start using another component that is vulnerable to injection attacks?
• By restricting certain characters you're potentially leaking information to an attacker about the makeup of underlying systems. e.g. you're using SQL. This could have ramifications if you do not then apply your input validation rules consistently.

The best solution, in my opinion, is to escape every string that you inject into SQL, HTML, XML, etc, regardless of its source. If you need to inject an unescaped string, then you need to apply rigorous, custom validation. (As Slashdot does with comments, for example.)

I think your solution is ok as a concept to reduce risk, but it introduces several other risks and introduces some new maintenance hassles that are best avoided.

Also, it reduces the security of passwords. :-)

You're thinking of M-expressions, which the linked-to site explains as being the initially intended external representation of Lisp (as in the language in which you would write code), but which never came to fruition, in large part because S-expressions (whence comes the backronym "Lots of Irritating, Superfluous Parentheses") are easy to throw around as data and that's a Good Thing, because it gives rise to macros, one of Lisp's most powerful features.

And Graham's thoughts on the Hindly-Milner type inference used in modern functional languages with REPLs (e.g. OCamlare...?

95% of the time you you type in no type annotations, and 4.99 of the other 5% of the time it's when you're using something like variant types. For the added safety (and other benefits, like making debugging with a REPL much easier) of the strong type system, Graham's position as stated above is greatly weakened.

Naturally it was used for many things.

So GPL is a license for Free/Open Source Software, and CDDL/Eclipse are licenses for submarines.

More info at http://erights.org.
The ACL model (based on the notion of principal) is limited because it doesn't scale (your access matrix grows fast as you need finer level access control) and still allows compromised applications to use their permissions for the wrong purpose (confused deputy problem).

I'm working on a project at the moment that's all Javascript on the client side and mod_python (with the very nice Publisher handler on the server. I have a simple Javascript wrapper around XMLHttpRequest for making asynchronous calls to the server (using CPS with Javascript closures as the "continuations") and I just pass all the info back in JSON format, so I can just eval() the returned text.

Surprisingly neat and (very) surprisingly flexible - you can also do stuff like pass back Javascript functions (from the server) along with the data you wish to process.

You can use the Python str() function for the most simple data conversions (eg. an array or a dictionary), but I prefer the pyjsonrpc package which has very nice little objToJson and jsonToObj functions. Better than just using Python's str() function, as it also strips out excess whitespace. I also modified it slightly to also properly convert Python booleans to Javascript booleans (it already handled null to None conversions).

It all works very nicely, a testament to the power of simplicity. The Javascript (client) side just makes requests in response to user actions (eg. button clicks) or other events, and the server responds to those requests with Javascript data (CPS is very well suited to this kind of programming).

Javascript really is a very cool programming language. I've implemented my own python.js library which adds a handful of Python-like functional programming facilities to Javascript (eg. map, filter, reduce) and dictionary/object methods like keys() and values(). It's got to the point now where I sometimes get confused as to whether I'm writing Javascript or Python, because they're so similar in all the ways that really matter.

This kind of web development is quite fun. I also have a nice advantage with the web application I'm working on, as it flat-out can't run on IE (it uses fixed-positioned divs quite extensively, along with a few other standard features that IE can't handle) and so I don't have to worry about compatibility with that fucking mess of a browser. Hooray. :-)

Since when is JavaScript a subset of Java and C? Refer to http://c2.com/cgi/wiki?JavaScript

To make an analogy, it's like buffer overflows in C/C++. Sure, it's possible to write C/C++ code which doesn't have explotable buffer overflows -- the techniques to avoid them are widely known and well documented. However, even extremely talented, security minded programmers STILL wind up making classic mistakes.

If you're worried about buffer overflows in your system, you could take two approches: you could implement it in C/C++ and adopt a very rigorous set of development procedures with extensive code reviews and testing, or you could use a language which is not vulnerable to buffer overlows. Which method do YOU think is going to require less effort and have a greater chance of succeding? Likewise, if you're worried about SQL injections, which is a better approach: one which requires you to not make any mistakes, or one which which won't let you make the mistake in the first place?

If even the hacker gods can't use the tool securely 100% of the time, what chance do we mere mortals have of doing so? The answer is, none at all. Therefore, sound engineering practice dictates that we take our human limitations into account and use tools and techniques which will mitigate the damage caused by those mistakes which we will inevitably make.

Here's another thing to consider: even if we can guarantee that our code is 100% free of exploitable holes, we still have to deal with the possibility that some other vulnerability (say in the operating system or the web server) will allow an attacker to compromise the public server. If all the security is on the web server, we've created single point of failure which will cause the entire system to be subverted.

An attacker who rooted the web server would be able to find out the database connection information, and would then therefore be able to connect to the database with the same permissions as the web application uses. If the web application has permission to read, update, and delete all tables, so does the attacker. If, however, we follow the principle of least privilidge, the public account only has permission to execute a limited set of well-designed stored procedures. This way, having direct access to the database doesn't allow the attacker to do anything that he wouldn't be able to do via the application.

Furthermore, we should practice defense in depth, which means putting in in redundant security features, compartmentalizing the application logic between the web server and the database server, and putting the components on seperate physical machines. This limits the damage which can be done if any single component fails. The fact that this architecture gives us better scalability is a free bonus.

A good engineer always asks himself "If THIS component fails, how will the entire system react?" Using an monolithic security model in a mission-critical system is bad engineering. A software engineer who designs an application which can be compromised by a single line of bad code is just as negligent as a civil engineer who designs a suspension bridge which will collapse if a single cable breaks.

To make an analogy, it's like buffer overflows in C/C++. Sure, it's possible to write C/C++ code which doesn't have explotable buffer overflows -- the techniques to avoid them are widely known and well documented. However, even extremely talented, security minded programmers STILL wind up making classic mistakes.

If you're worried about buffer overflows in your system, you could take two approches: you could implement it in C/C++ and adopt a very rigorous set of development procedures with extensive code reviews and testing, or you could use a language which is not vulnerable to buffer overlows. Which method do YOU think is going to require less effort and have a greater chance of succeding? Likewise, if you're worried about SQL injections, which is a better approach: one which requires you to not make any mistakes, or one which which won't let you make the mistake in the first place?

If even the hacker gods can't use the tool securely 100% of the time, what chance do we mere mortals have of doing so? The answer is, none at all. Therefore, sound engineering practice dictates that we take our human limitations into account and use tools and techniques which will mitigate the damage caused by those mistakes which we will inevitably make.

Here's another thing to consider: even if we can guarantee that our code is 100% free of exploitable holes, we still have to deal with the possibility that some other vulnerability (say in the operating system or the web server) will allow an attacker to compromise the public server. If all the security is on the web server, we've created single point of failure which will cause the entire system to be subverted.

An attacker who rooted the web server would be able to find out the database connection information, and would then therefore be able to connect to the database with the same permissions as the web application uses. If the web application has permission to read, update, and delete all tables, so does the attacker. If, however, we follow the principle of least privilidge, the public account only has permission to execute a limited set of well-designed stored procedures. This way, having direct access to the database doesn't allow the attacker to do anything that he wouldn't be able to do via the application.

Furthermore, we should practice defense in depth, which means putting in in redundant security features, compartmentalizing the application logic between the web server and the database server, and putting the components on seperate physical machines. This limits the damage which can be done if any single component fails. The fact that this architecture gives us better scalability is a free bonus.

A good engineer always asks himself "If THIS component fails, how will the entire system react?" Using an monolithic security model in a mission-critical system is bad engineering. A software engineer who designs an application which can be compromised by a single line of bad code is just as negligent as a civil engineer who designs a suspension bridge which will collapse if a single cable breaks.

The ORM layer is a weakness I think, the author is clearly not interested in understanding the relational model and has admitted as such in the mailing list. He commits the The First Great Blunder.

A bit off topic, but the first great blunder that you refer to is not exactly universally accepted as an irrefutable truism. That being the case, this doesnt seem to a major barrier to me. My understanding is that the ORM layer is based on the ActiveRecord pattern which is described by Martin Fowler in his book Patterns of Enterprise Application Architecture.

For most sites, Rails is fine. Don't worry about it unless you have an actual problem (bad benchmark, data integrity issue).

The ORM layer is a weakness I think, the author is clearly not interested in understanding the relational model and has admitted as such in the mailing list. He commits the The First Great Blunder. And he puts data integrity logic in the framework (which is like the Zero'th Great Blunder in my opinion).

However, note that the ORM layer is totally optional. You can use any ORM layer you want, including one you might write yourself using a more finely-tuned way of accessing the database. I have a custom DB layer I use and the rest of rails is quite happy with it.

Greets!

It really is a poisinous, nasty piece of hatchet journalism, wearing nice clothes.

John's full reply is still archived and available at: http://xanadu.com.au/mail/xanadu/msg00258.html.

Ted's reply is also available:
http://xanadu.com.au/wolfsbane

And the c2 page http://c2.com/cgi/wiki?TheCurseOfXanadu

Adam Moore, Postdoc Researcher, ZigZag for Bioinformatics

Do you happen to know if your MAC can run PERL?

Which is the point I was trying to make with you.

That's dynamite. Except that 60% of my window isn't too wide, my window isn't too large, and they wasted a large part of it they could have used, and that's bad or at least lazy design. Which was the point I was making.

Would you rather have that space filled with blinking advertisements?

False Dichotomy.

<?xml version="1.0"?>

<example_program>

<function name="max">

<param name="p1" type="int" />
<param name="p2" type="int" />
<return type="int" />

<body>
<if>
<expr>
<gt left="p1" right="p2" />
</expr>
<return val="p1">
<else>
<return val="p2">
</else>
</if>

</body>

</function >

<function name="main">
<body>

<var name="result" type="int">
<call function="max">
<param value="1" />
<param value="2" />
</call>
</var>

</body>
</function>

</e xample_program>

Programming with boxes and wires is the way you code in such languages.

The 1980s just called, they want their silver bullet back.