Slashdot Mirror

Snowboard technology stabilized in the early 90s (vertically laminated wood cores, steel edges, radial sidecuts, cap or sidewall construction, etc, all basically like wide skis with tight sidecut radii). Then the progression in snowboard design seemed to reach a plateau - new gimmicks were introduced, and they sold boards, but didn't make much difference.

But in the last few years, a few shops have popped up that will make boards to order. Now you can pick your length, width, sidecut radius, and flex pattern (and how much do you weigh?), and get a board made to order, for not much more than a production board. The freeride and freestyle people haven't taken much advantage of this, but the carvers and racers totally have.

Donek - kind of expensive, but they have a dedicated following among carvers

Prior - also lurking beneath the brand-name logos of various professional racers

Coiler - inexpensive, perhaps because of the Canadian dollar, and they kick much ass

CustomCraft - only custom shop I know of that mostly builds freestyle and freeride boards

The technology of the boards themselves isn't revolutionary, the cool thing is the technology that lets these builders give you a high-quality made-to-order board at a totally reasonable cost.

I have no affiliation with any of the above companies, but I do have an alpine board from Coiler and an alpine/freeride hybrid from CustomCraft. Both have saved me the trouble of searching through piles of catalogs to find a board with the specs I want, and both have given me the confidence to push my envelope further, after 15 years of riding mass-produced boards.

If you want to play with the numbers before having a board built, I have a web-based calculator that you might get a kick out of.

Gotta run. There's a lot to be said about snowboard binding development too, maybe later.

[...] those ideas are usually not backed by a lot of practical experience.

True, but if he's willing to separate wheat and chaff, there's probably enough people here who know what they're talking about that asking here will not have been a waste of his time.

Especially if he's not discouraged by the e-holes ridiculing him for thinking big. While it's true that he probably won't realize all of his goals, before he's done he will have learned a lot and had a lot of fun. What else matters?

Anyhow, I have a bit of experience (and some of it with a not-completely-unrelated project), so I thought I'd chime in.

First, not coding yet is a good idea, and one that's lost on a lot of people. Think first, design, plan, write down your designs and plans (the very act of writing forces you to think about them more), and re-read them to think about them some more. Better yet, find some like-minded people to critique your designs and plans. They'll see things you won't.

Changing designs is easy and painless when you've only invested a couple paragraphs. It's a huge pain in the ass when you've invested hours or weeks or months.

I used to work for a manager who believed that with a good design document, you could hire a semi-talented high school student to do the coding. I think that's design documentation beyond the point where diminishing returns sets in, but on the other hand, you I also believe that if you know what it is you're going to create, you can't write too much design documentation. XP and "agile programming" are great for situations in which the client changes the requirements regularly, but if you have a clear picture of what you're creating, it's worth spending lots of time on documentation. In my experience it saves far more time than it costs.

Design the user interface, and write that down, in detail.

Do a high-level design of the whole system - what are the objects, what are their responsibilities, and how to they communicate?

For each class, do a detailed design. How does it carry out its responsibilities?

Then re-read the whole thing and look for issues that you didn't see when you started. Have a teammate reread the whole thing and look for issues. Look for assumptions you didn't know you had. Look for objects that have been tasked with doing things that they can't do with the information or interfaces they have available.

Then figure out a game plan, a timeline, that will get you a minimal application with at least some usable functionality. That gives you a gratifying achievable goal to shoot for, and it gives you something functional to (hopefully) help keep you inspired.

Good luck.

[...] those ideas are usually not backed by a lot of practical experience.

True, but if he's willing to separate wheat and chaff, there's probably enough people here who know what they're talking about that asking here will not have been a waste of his time.

Especially if he's not discouraged by the e-holes ridiculing him for thinking big. While it's true that he probably won't realize all of his goals, before he's done he will have learned a lot and had a lot of fun. What else matters?

Anyhow, I have a bit of experience (and some of it with a not-completely-unrelated project), so I thought I'd chime in.

First, not coding yet is a good idea, and one that's lost on a lot of people. Think first, design, plan, write down your designs and plans (the very act of writing forces you to think about them more), and re-read them to think about them some more. Better yet, find some like-minded people to critique your designs and plans. They'll see things you won't.

Changing designs is easy and painless when you've only invested a couple paragraphs. It's a huge pain in the ass when you've invested hours or weeks or months.

I used to work for a manager who believed that with a good design document, you could hire a semi-talented high school student to do the coding. I think that's design documentation beyond the point where diminishing returns sets in, but on the other hand, you I also believe that if you know what it is you're going to create, you can't write too much design documentation. XP and "agile programming" are great for situations in which the client changes the requirements regularly, but if you have a clear picture of what you're creating, it's worth spending lots of time on documentation. In my experience it saves far more time than it costs.

Design the user interface, and write that down, in detail.

Do a high-level design of the whole system - what are the objects, what are their responsibilities, and how to they communicate?

For each class, do a detailed design. How does it carry out its responsibilities?

Then re-read the whole thing and look for issues that you didn't see when you started. Have a teammate reread the whole thing and look for issues. Look for assumptions you didn't know you had. Look for objects that have been tasked with doing things that they can't do with the information or interfaces they have available.

Then figure out a game plan, a timeline, that will get you a minimal application with at least some usable functionality. That gives you a gratifying achievable goal to shoot for, and it gives you something functional to (hopefully) help keep you inspired.

Good luck.

No multiple-inheritance ( before you cry: having 20 level inheritance trees from 3 different objects SUCKS in any language, but occasionally deriving from more than one object comes handy once in a while)

Oh quit your bitching. Want to reuse the same few functions across a set of classes? That's what the clipboard is for. You know, copy and paste. Just paste that useful code into every class that needs it.

Want to change, extend, or trim back that code that cut-pasted code that should have been a base class? That's what search-and-replace is for. You've got a lovely IDE, learn to use it.

Me? Bitter?

Seriously though, I've been thinking about creating a language called D. D is a half-step above C#. D will look just like C#, but it will add a new keyword: derivesfrom. Then you can write code like this:

public class BaseClass
{
// implementation and stuff goes here
}

public class Widget derivesfrom BaseClass, OtherBaseClass : IWhatever, ISomethingElse
{
// you know
}

The D "compiler" will read such things and emit perfectly compilable C# code, sparing you the cut-paste madness known as "code reuse" in the C# world. The only question is whether D should be implemented as a perl script (because I have a sense of humor) or as a D application (because geeks (like me) are fond of self-reference).

As a friendly gesture to those who oppose MI, the D compiler will spit out an error message if you attempt to derive from two classes that share a common base class. This one pathological example seems to have scared the bejeezus out of language designers everywhere. Other abuses of MI might be handled with stern warnings.

I submitted the project to the good people at SourceForge a few minutes ago. In the meantime, contact me directly if you're interested in bringing D to fruition.

MDI is sweet. It's a great tool. Not the right tool for all jobs, but it's the right tool for some jobs.

The tabbed approach is great too - I'm using it now in Mozilla. But, if you want to be able to view, compare, or monitor multiple documents at once, tabbing blows. MDI handles that much better.

And then there's the situation where an app needs multiple views on a single document. MDI is the right tool for that job.

Someone bitched about MDI using "full screen windows..." Duh. Don't maximize and you won't have that problem. Someone bitched about switching between child windows. Waaah. Use ctrl-tab to traverse the children. (The programmer has the option of taking that a step further, traversing the child windows on an MRU basis.)

Pick the right tool for the job. MDI has its place, tabbing has its place. Both kick ass. Neither sucks.

MDI is sweet. It's a great tool. Not the right tool for all jobs, but it's the right tool for some jobs.

The tabbed approach is great too - I'm using it now in Mozilla. But, if you want to be able to view, compare, or monitor multiple documents at once, tabbing blows. MDI handles that much better.

And then there's the situation where an app needs multiple views on a single document. MDI is the right tool for that job.

Someone bitched about MDI using "full screen windows..." Duh. Don't maximize and you won't have that problem. Someone bitched about switching between child windows. Waaah. Use ctrl-tab to traverse the children. (The programmer has the option of taking that a step further, traversing the child windows on an MRU basis.)

Pick the right tool for the job. MDI has its place, tabbing has its place. Both kick ass. Neither sucks.

"If you want random pseudonymous people putting arbitrary files on your machine, be my guest, but don't cry to me when they put on your machine files which you don't want."

Back when 99% of the 'random pseudonymous people' turned out to be people who were contacting me to discuss something I'd posted somewhere, there was no problem. When spammers started abusing this system for their own gain, a "tragedy of the commons" ensued.

Your "well established protocol" analogy is utterly useless. The well established protocol for email is that it is NOT for the mass distribution of unsolicited email on an opt-out basis. No mind reading necessary. Wake the fsck up and read your own ISP's acceptable usage policy. (whois, traceroute, and ARIN suggest that Verio is your ISP, if I'm wrong you'll have to find the AUP yourself...) The "protocol" hss been in writing ever since spammers started pissing in the pool. Smaller ISPs caught on early, but even giants like MCI were catching on by 1996 and now you'd be hard-pressed to find an ISP that doesn't subscribe to the same "protocol." And if your ISP doesn't, you can expect most of your outgoing mail to bounce.

That said, as a practical matter, the only way to be free from spam is to make it difficult for 'random pseudonymous people' to get into your mailbox. Unless junk email gets regulated like junk fax, I expect whitelisting to catch on in a big way. In a few years, people will simply expect their first email to someone to bounce back with a message that says something like "please reply to this message with the subject line intact, unless you are a spammer." Three-way handshake will be the norm, not the exception.

My $0.02: LCP, penalty method, lagrange multiply, impluse method... some such physical simulation algorithm will belong in the list eventually (or maybe a few of them will). Probably a collision detection algorithm too, maybe nice fast polygon soup algorithm.

This stuff is pretty niche right now (mostly just games and high-end simulations), but I think it will get find more widespread application as computing power increases.

a cool LCP implementation

a fun toy (yes, I'm biased) that uses the above