My suggestion is not to focus on a particular problem -> solution, but to think more open-ended. In essence, think of some general functionality that can be continually extended. Maybe an example will help clarify:)
When I taught myself python, I first wrote a program that determined the word-wrap properties of a text file. It detected wrapping behavior across lines, and then constructed a range of possible wrap settings. I then added tabwidth detection. After this, I began to think about interpreting text structure from a document. So, if a block of lines exhibit wrap behavior, they're a paragraph, otherwise perhaps a section of code or a title. Then, I wrote a parser that accepted call backs, so, for example, it could (very roughly) convert etexts into html. Of course, this all took place over a week or so, and my knowledge of python evolved accordingly.
So, my suggestion is don't think "final product," but rather work on a general library of functionality that you can extend as you go.
I was actually logging back on to mention exactly what you've pointed out. My post was just a gut response to the LGF post claiming exact correlation, so I did my own experiment and that was the main thing I noticed. I've just started thinking about the vagaries of printing, and I indeed agree that any comparison between screen rendering and print is largely circumspect.
I've been reading about this for roughly an hour, and one of the major issues is the position of the "th". Many claim that these documents were obviously prepared in Word, as it automatically superscripts the "th". I'd like to point out that in the memos, the "th" appears differently than in Word. In the memos, the th partially exceeds the top of the letters around it, whereas in Word, the top of the "h" is matches with the top of the other letters. An attempt at an example:
Personally, I deal with different technologies, using ASP.NET (the horror!) to craft a rather random assortment of inhouse management tools for an IT organization, but many of the issues we face are the same. From ye olde days of ASP 3.0 with the ugliness of "includes" to a modular, n-tier approach, I'm always left with an unshakeable feeling that things could have been done better. The kludge that is modern web application interface (that is to say, HTML, J(ava)Script, etc) are too scattered and poorly supported to make anything approaching an "elegant" web application. (Btw, I'd love to be proved wrong here...).
Here are the few suggestions I have which I can confidently say have improved my productivity. There probably the same things that everyone has come across, but maybe if I throw them out here I can invite some discussion.
Separate the task-at-hand and its implementation logic from the presentation layer. For instance, I normally write all of my business logic and database code as if it were just going to be an entirely separate library, and not particularly targetted towards web dev. This not only enforces solid library design principles, but allows me to debug and test using simple command line interfaces to the library. Approaching your code from a new direction (in this case simple user apps) frequently opens up entirely new ideas and perspectives. Once you've done this, the majority of your "behind-the-scenes" web code can just be a wrapper for this library, and then all you have left is the presentation logic. This has helped me immensely in the areas of scalability/integration and portability.
Second, never ever do any cosmetic presentation work until you're absolutely sure you have a beta (or better) quality base of business logic you're prepared to stand by. Adding the presentation logic to a web app too early is sort of like munging in command line options to a good ole console app: if done improperly, things quickly get out of hand and you have to code in more global scope hacks than you'd like to admit. Personally, after many bad experiences with this problem, I do *all* my testing on blatantly ugly hand-crafted html pages until I'm sure I've got things right.
Third, don't focus on a "page" as a discrete, targeted development object. Rather, the actual pages should be afterthoughts. Try to engineer solid "user-interface" components, and then plan on the final web pages as simple composites of these components. I estimate that, when I sketch out my initial concept of the pages and interface layer of a web app, more than 50% of the various tasks presented to the user will change drastically in scope before I'm even done developing. You realize that certain tasks just aren't needed, certain things are inconvenient, etc and using a component model to the presentation layer helps reconfiguring immensely. One of the biggest frustrations with web application is that, when different ideas are flying through your mind, its difficult to figure out all that must be coded in order to test them out. You think, "hmm this might work!" and find yourself having to chase down random bugs and make changes in five different files just to get a prototype working. Using a component model helps quite a bit in this department.
In terms of architecture, the only vaguely successful model I've come across is (once you've got a solid library backing you up...) model your application as a set of distinct user tasks. Allow each task to develop independently, and the step back and look at where the overlap is and what components are a good candidate for integration. Taking things on a task-by-task basis at the beginning helps immensely in bug detection also, because you're only focusing on one coherent progression of logic at a time.
I realize that most of this is probably old news to any qualified web dev, but this is the stuff I have to continually force myself to do after two years in the biz, so perhaps it is of some use. Any comments, suggestions, rebuttals, etc I'd be glad to hear.
Type yahoo in IE then hit CTRL+Enter and you will understand. Saves a lot of typing.
Works in Konqueror;-)
You might also be interested in the Web Shortcuts feature, which lets the user define abbreviations for building GET requests. For instance, if you type "gg:some words to search for" in the location box, you are taken directly to the Google results page for a basic query on those words.
The last time I checked, there was no support for the standard dreamcast modem in the linux distribution. There is support for the broadband adapter, but that raises two issues: 1) I seriously doubt your grandmother has broadband access given your description of her computer use and 2) the broadband adapter is extremely hard to find, occasionally surfacing on ebay and selling in excess of $120.
I have no experience with running NetBSD on my dc, but a quick check of the page seems to indicate that it too lacks modem drivers.
Without a doubt, go for the standard Sega tools and utilities. Its cool to be able to run Linux and emulators, but believe me, you are well aware during the experience that you are running these ports on a gaming console. You have no permanent storage, I believe drivers are in the works to allow you to use the vmu, but they're small anyway. Thus, you can't save settings (network connectivity information), unless you load information over the network using the broadband adapter or a special serial device you can order from Lik Sang, but I think these requirements certainly exceed the scope of the project you're undertaking.
Good luck and let us know what you end up doing, and if you're successful in getting your grandmother online, I've got a couple of similar situations in my family.
I don't believe it's fully accurate to say that screenshot demonstrates translucent windowing in Linux. Yes it demonstrates the persistance of the appearance of windows below into windows above, but the examples present (the Liquid theme on the KDE Panel and Konsole) are special features of the applications and in no way a component of the operating system or desktop environment. The Liquid Theme is great, I'm using it right now, and it does have cool transparent menus, but its a special property of the widget (I believe, please correct me if wrong), as opposed to the transparency system in XP, which is a hardware accelerated component of the underlying GUI system. Konsole, furthermore, offers "transparency" as an option under Schema, but its not truly transparent, rather, it regrabs the desktop's background and paints it behind the console's text each time the window is moved.
I love KDE and I think the screenshot shows two cool examples of its power, but this is nowhere near the technology I believe the poster was referring to. I'm not very familiar with X programming, but could someone share some more technical aspects of what would be required architectually and programmatically to get this working under Linux?
I hate to be negative here, especially because this looks so cool and is running Linux on a Transmeta cpu, but how useful could this ever really be to the average geek?
I understand that this might be great for those unable to get around or confined to bed, as it would be small and unobtrusive and allow easy access to the net, but at a pricetag of $600, could this ever be justified for someone perfectly capable of getting up and walking 15 feet to their machine?
For around $600, this looks like it might make a great living room terminal.
A great living room terminal? Do you really feel the need for a living room terminal? I spend about 10 hours a day in front of my machine, seriously, and that'd be more if I was working instead of attending class. When factoring in sleep (which is becoming less and less) and eating and simple things like transportation, I have very little time for anything else, and I very rarely find myself sitting around *itching* for the Internet, because normally I'm right there in front of it. I can't really imagine myself sitting in a recliner and thinking, "damn I wish I could get on the Internet but that'd mean I'd have to walk all the way over there, and use a keyboard, nahh I'll just sit here."
Also, configuration/ease of use becomes an issue, because I like to be webbrowsing in a comfortable and familiar environment, where I have my bookmarks at hand, I have my mp3s playing, I have Kinkatta up so people can IM me, I've got about 25 windows open, maybe even KVirc on #debian; in other words, if I'm only 15 feet from my computer, I'd rather just get up and go full Internet mode than sit around, dealing with a small screen and uncomfortable interface. Yes I read the specs and saw that it offers a "full" range of Internet tools, but you ever try to communicate on IRC with handwriting recognition?
Basically, I can't see buying one of these as anything but self-indulgence, unless of course you have an understandable need such as a disability preventing you from using a regular computer/terminal set up. If I had a spare $600 to burn on geekstuff that I'd never fully use, I'd think about building a cluster or an mp3 jukebox/mapping+gps system for my car, at least I'll have the parts left over in a couple months after I realize how little I used it.
Sorry to be so cynical, but after dropping $500 on a PDA that I only used to play Doom and for playing mp3s and it didn't help me get organized one bit, I've started to rethink my approach to gadgets.
This draws from my experience administering WinNT 4 and 2k so I might miss lots of things (please flame away), but there are a variety of options for remote installation and management of machines in a Win2k environment.
First, there's the RIS system, which allows you to set up a server with a custom CD image (the normal Win 2k Pro image works fine but you can also slipstream service packs and updates as needed). Then, you create boot floppies. So long as you make a machine acount with the proper MAC (captured in the GUID) address of the machine you want to build, you simply boot from the floppy, it finds the RIS server, and builds itself. You can set up scripts to install/customize applications once the machine build is complete.
After that, the Active Directory can be used to advertise policies, which can inclue software updates, service packs, and a variety of things. I don't have much experience there, so maybe somebody else can offer info.
Finally, the big end-all of Microsoft distributed network management is SMS, this behemoth (which is as difficult to administer as Exchange) not only provides a huge SQL DB of all inventory information, but you can use it to distribute and control practically any possible software update necessary, such as remotely instructing a machine to upgrade itself from Win98 to Windows2000 at 4:00 am (or after the user logs off if someone is logged on at that time).
In short, and its difficult to say, and I'm in no way a fan of Microsoft (running Debian for two years now), but Win2k does actually provide a robust and featureful means of remotely managing computers. And quite naturally, there are components for license management. The problem is, it's all so complex. In my group, we looked long and hard at SMS, and even licensed a copy of BackOffice, but we soon realized it was just beyond our scope to implement. It's hard to make the senior guys understand that in order to keep the machines up to date, you need to hire as many additional people as you do for email (Exchange). They say "but what did we hire you for?" The tools Microsoft provides are very powerful, more powerful than I think a lot of people realize, but they're just so complex that I don't think they offer much to the worked-his-way-up-from-tech-support-admin. It takes months of planning and education to successfully implement and maximize any of these options, and I don't think many organizations can spare their top admins for that long.
This is where I think GNU/Linux (specifically Debian) has a great chance, one I'm aggressively trying to push in my organization. All one has to do is set up a server with the debian mirror scripts, run an in house mirror that updates nightly (be sure to make a reasonable contribution if you're gonna be downloading a lot). Then, using simple bootfloppies with some scripts, you can boot and build machines with minimal configuration, which then download and install everything from your local mirror. All you have to do is set up the appropriate servers, once again easy with debian, have each machine mount/home off of a share somewhere, and you're good to go, a robust and nightly updated (simple cron jobs) system.
To me, apt-get is a next generation tool that significantly alters the paradigm of computer usage. Once you make the switch to apt, you never go back. It completely alters how one looks at building, managing, and upgrading PC's, and I think it, along with samba, are the two best selling points to Linux in corporate IT world.
Wow, sorry to have gone off a bit here, but it's Friday and I'm bored. As always, these are just my opinions, and your mileage may very. Feel free to flame away, I'm interested to hear what people have to say.
Slashdot Mirror
My suggestion is not to focus on a particular problem -> solution, but to think more open-ended. In essence, think of some general functionality that can be continually extended. Maybe an example will help clarify :)
When I taught myself python, I first wrote a program that determined the word-wrap properties of a text file. It detected wrapping behavior across lines, and then constructed a range of possible wrap settings. I then added tabwidth detection. After this, I began to think about interpreting text structure from a document. So, if a block of lines exhibit wrap behavior, they're a paragraph, otherwise perhaps a section of code or a title. Then, I wrote a parser that accepted call backs, so, for example, it could (very roughly) convert etexts into html. Of course, this all took place over a week or so, and my knowledge of python evolved accordingly.
So, my suggestion is don't think "final product," but rather work on a general library of functionality that you can extend as you go.
I was actually logging back on to mention exactly what you've pointed out. My post was just a gut response to the LGF post claiming exact correlation, so I did my own experiment and that was the main thing I noticed. I've just started thinking about the vagaries of printing, and I indeed agree that any comparison between screen rendering and print is largely circumspect.
Word is this...whereas the memo is...
I feel ya.
...).
Personally, I deal with different technologies, using ASP.NET (the horror!) to craft a rather random assortment of inhouse management tools for an IT organization, but many of the issues we face are the same. From ye olde days of ASP 3.0 with the ugliness of "includes" to a modular, n-tier approach, I'm always left with an unshakeable feeling that things could have been done better. The kludge that is modern web application interface (that is to say, HTML, J(ava)Script, etc) are too scattered and poorly supported to make anything approaching an "elegant" web application. (Btw, I'd love to be proved wrong here
Here are the few suggestions I have which I can confidently say have improved my productivity. There probably the same things that everyone has come across, but maybe if I throw them out here I can invite some discussion.
Separate the task-at-hand and its implementation logic from the presentation layer. For instance, I normally write all of my business logic and database code as if it were just going to be an entirely separate library, and not particularly targetted towards web dev. This not only enforces solid library design principles, but allows me to debug and test using simple command line interfaces to the library. Approaching your code from a new direction (in this case simple user apps) frequently opens up entirely new ideas and perspectives. Once you've done this, the majority of your "behind-the-scenes" web code can just be a wrapper for this library, and then all you have left is the presentation logic. This has helped me immensely in the areas of scalability/integration and portability.
Second, never ever do any cosmetic presentation work until you're absolutely sure you have a beta (or better) quality base of business logic you're prepared to stand by. Adding the presentation logic to a web app too early is sort of like munging in command line options to a good ole console app: if done improperly, things quickly get out of hand and you have to code in more global scope hacks than you'd like to admit. Personally, after many bad experiences with this problem, I do *all* my testing on blatantly ugly hand-crafted html pages until I'm sure I've got things right.
Third, don't focus on a "page" as a discrete, targeted development object. Rather, the actual pages should be afterthoughts. Try to engineer solid "user-interface" components, and then plan on the final web pages as simple composites of these components. I estimate that, when I sketch out my initial concept of the pages and interface layer of a web app, more than 50% of the various tasks presented to the user will change drastically in scope before I'm even done developing. You realize that certain tasks just aren't needed, certain things are inconvenient, etc and using a component model to the presentation layer helps reconfiguring immensely. One of the biggest frustrations with web application is that, when different ideas are flying through your mind, its difficult to figure out all that must be coded in order to test them out. You think, "hmm this might work!" and find yourself having to chase down random bugs and make changes in five different files just to get a prototype working. Using a component model helps quite a bit in this department.
In terms of architecture, the only vaguely successful model I've come across is (once you've got a solid library backing you up...) model your application as a set of distinct user tasks. Allow each task to develop independently, and the step back and look at where the overlap is and what components are a good candidate for integration. Taking things on a task-by-task basis at the beginning helps immensely in bug detection also, because you're only focusing on one coherent progression of logic at a time.
I realize that most of this is probably old news to any qualified web dev, but this is the stuff I have to continually force myself to do after two years in the biz, so perhaps it is of some use. Any comments, suggestions, rebuttals, etc I'd be glad to hear.
Mike
I have a feeling 300,000 slashdot readers will take care of Verio's traffic problem real quick.
Type yahoo in IE then hit CTRL+Enter and you will understand. Saves a lot of typing.
;-)
Works in Konqueror
You might also be interested in the Web Shortcuts feature, which lets the user define abbreviations for building GET requests. For instance, if you type "gg:some words to search for" in the location box, you are taken directly to the Google results page for a basic query on those words.
The last time I checked, there was no support for the standard dreamcast modem in the linux distribution. There is support for the broadband adapter, but that raises two issues: 1) I seriously doubt your grandmother has broadband access given your description of her computer use and 2) the broadband adapter is extremely hard to find, occasionally surfacing on ebay and selling in excess of $120.
I have no experience with running NetBSD on my dc, but a quick check of the page seems to indicate that it too lacks modem drivers.
Without a doubt, go for the standard Sega tools and utilities. Its cool to be able to run Linux and emulators, but believe me, you are well aware during the experience that you are running these ports on a gaming console. You have no permanent storage, I believe drivers are in the works to allow you to use the vmu, but they're small anyway. Thus, you can't save settings (network connectivity information), unless you load information over the network using the broadband adapter or a special serial device you can order from Lik Sang, but I think these requirements certainly exceed the scope of the project you're undertaking.
Good luck and let us know what you end up doing, and if you're successful in getting your grandmother online, I've got a couple of similar situations in my family.
I don't believe it's fully accurate to say that screenshot demonstrates translucent windowing in Linux. Yes it demonstrates the persistance of the appearance of windows below into windows above, but the examples present (the Liquid theme on the KDE Panel and Konsole) are special features of the applications and in no way a component of the operating system or desktop environment. The Liquid Theme is great, I'm using it right now, and it does have cool transparent menus, but its a special property of the widget (I believe, please correct me if wrong), as opposed to the transparency system in XP, which is a hardware accelerated component of the underlying GUI system. Konsole, furthermore, offers "transparency" as an option under Schema, but its not truly transparent, rather, it regrabs the desktop's background and paints it behind the console's text each time the window is moved.
I love KDE and I think the screenshot shows two cool examples of its power, but this is nowhere near the technology I believe the poster was referring to. I'm not very familiar with X programming, but could someone share some more technical aspects of what would be required architectually and programmatically to get this working under Linux?
I hate to be negative here, especially because this looks so cool and is running Linux on a Transmeta cpu, but how useful could this ever really be to the average geek?
I understand that this might be great for those unable to get around or confined to bed, as it would be small and unobtrusive and allow easy access to the net, but at a pricetag of $600, could this ever be justified for someone perfectly capable of getting up and walking 15 feet to their machine?
For around $600, this looks like it might make a great living room terminal.
A great living room terminal? Do you really feel the need for a living room terminal? I spend about 10 hours a day in front of my machine, seriously, and that'd be more if I was working instead of attending class. When factoring in sleep (which is becoming less and less) and eating and simple things like transportation, I have very little time for anything else, and I very rarely find myself sitting around *itching* for the Internet, because normally I'm right there in front of it. I can't really imagine myself sitting in a recliner and thinking, "damn I wish I could get on the Internet but that'd mean I'd have to walk all the way over there, and use a keyboard, nahh I'll just sit here."
Also, configuration/ease of use becomes an issue, because I like to be webbrowsing in a comfortable and familiar environment, where I have my bookmarks at hand, I have my mp3s playing, I have Kinkatta up so people can IM me, I've got about 25 windows open, maybe even KVirc on #debian; in other words, if I'm only 15 feet from my computer, I'd rather just get up and go full Internet mode than sit around, dealing with a small screen and uncomfortable interface. Yes I read the specs and saw that it offers a "full" range of Internet tools, but you ever try to communicate on IRC with handwriting recognition?
Basically, I can't see buying one of these as anything but self-indulgence, unless of course you have an understandable need such as a disability preventing you from using a regular computer/terminal set up. If I had a spare $600 to burn on geekstuff that I'd never fully use, I'd think about building a cluster or an mp3 jukebox/mapping+gps system for my car, at least I'll have the parts left over in a couple months after I realize how little I used it.
Sorry to be so cynical, but after dropping $500 on a PDA that I only used to play Doom and for playing mp3s and it didn't help me get organized one bit, I've started to rethink my approach to gadgets.
Just my $0.02,
Mike
This draws from my experience administering WinNT 4 and 2k so I might miss lots of things (please flame away), but there are a variety of options for remote installation and management of machines in a Win2k environment.
/home off of a share somewhere, and you're good to go, a robust and nightly updated (simple cron jobs) system.
First, there's the RIS system, which allows you to set up a server with a custom CD image (the normal Win 2k Pro image works fine but you can also slipstream service packs and updates as needed). Then, you create boot floppies. So long as you make a machine acount with the proper MAC (captured in the GUID) address of the machine you want to build, you simply boot from the floppy, it finds the RIS server, and builds itself. You can set up scripts to install/customize applications once the machine build is complete.
After that, the Active Directory can be used to advertise policies, which can inclue software updates, service packs, and a variety of things. I don't have much experience there, so maybe somebody else can offer info.
Finally, the big end-all of Microsoft distributed network management is SMS, this behemoth (which is as difficult to administer as Exchange) not only provides a huge SQL DB of all inventory information, but you can use it to distribute and control practically any possible software update necessary, such as remotely instructing a machine to upgrade itself from Win98 to Windows2000 at 4:00 am (or after the user logs off if someone is logged on at that time).
In short, and its difficult to say, and I'm in no way a fan of Microsoft (running Debian for two years now), but Win2k does actually provide a robust and featureful means of remotely managing computers. And quite naturally, there are components for license management. The problem is, it's all so complex. In my group, we looked long and hard at SMS, and even licensed a copy of BackOffice, but we soon realized it was just beyond our scope to implement. It's hard to make the senior guys understand that in order to keep the machines up to date, you need to hire as many additional people as you do for email (Exchange). They say "but what did we hire you for?" The tools Microsoft provides are very powerful, more powerful than I think a lot of people realize, but they're just so complex that I don't think they offer much to the worked-his-way-up-from-tech-support-admin. It takes months of planning and education to successfully implement and maximize any of these options, and I don't think many organizations can spare their top admins for that long.
This is where I think GNU/Linux (specifically Debian) has a great chance, one I'm aggressively trying to push in my organization. All one has to do is set up a server with the debian mirror scripts, run an in house mirror that updates nightly (be sure to make a reasonable contribution if you're gonna be downloading a lot). Then, using simple bootfloppies with some scripts, you can boot and build machines with minimal configuration, which then download and install everything from your local mirror. All you have to do is set up the appropriate servers, once again easy with debian, have each machine mount
To me, apt-get is a next generation tool that significantly alters the paradigm of computer usage. Once you make the switch to apt, you never go back. It completely alters how one looks at building, managing, and upgrading PC's, and I think it, along with samba, are the two best selling points to Linux in corporate IT world.
Wow, sorry to have gone off a bit here, but it's Friday and I'm bored. As always, these are just my opinions, and your mileage may very. Feel free to flame away, I'm interested to hear what people have to say.
Mike
yes, the same logic weapons, drug dealers, and napster use