Reminds me of when we tried to play Super Dance Dance Fighter 2 Turbo. Basically Street Fighter but too lazy to undo the dance pads. Damned bastard picked Guile and just did Sonic Booms or Flash Kicks while I was stuck trying to do Kens Dragon Punch or Hurricane Kick. I learned my lesson, though- next match I picked Blanca...
A few sides to web2.0. One is tech (assume that client has Javascript and DOM that is worth a damn). Two is "you have access your information" (supposedly flickr, apis, etc). Three is communal, collaborative activities (ie: Digg, Reddit, dare I say Kuro5hin)... Flickr tags, wikipedia collaborative editing, delicious, etc.
This is different from:
web0.9 (publishers of static sites)
web1.0 (dynamic, interactive sites, cms)
web1.5 (...all of the 2.0 techs, but in bits and pieces...)
web2.0 (the future, in 3-d!)
So one half of it is tech, the other half is collaboration, the other half is api's.
So what if you have some reasonably complicated website with login, "stuff" and everything else, and you want to integrate some sort of message-board?
I've been working on a games website with a friend, where step #1 was "make games work". Now we're on step 3 or 4, which is "get forum software", but I haven't found any relevant sites discussing integrating some reasonably simple forum software with existing login systems.
There seems to be two schools of thought:
1- You are an end-user and "just want some discussion software, dammit", which is admittedly a large part of the market.
2- There is no two!
The well known software projects (phpBB, drupal, etc) all have a significant portion of user-management stuff, which I already have (and don't want!) due to the work that we've done on the main portion of the site.
My ideal would be some discussion software where I could override a "is_logged_in" function, and maybe a "link_to_profile" function and it provided all the rest of everything else.
Second place would go to some software where I could (easily!) create new forum users automatically and sync username / password changes pretty easily. It would be sub-optimal, but "ok" if users had to log in to the main site, and / or log in to the forum (ie: two separate cookies / login instances), but it's better than wasting time writting yet another forum / polling software thingy.
Lastly would be to rewrite all of "my" code to be based on the forum login / profile / identity stuff, but that's a huge PITA too...
Any recommendations or experiences? (would this make a good ask slashdot?)
Good web-hosts will let you choose between various versions on a per-domain basis. Dreamhost also gives you access to some bits of.htaccess files which I assume you could link *.php4 to the php4 cgi and vice versa for *.php5. Yeah, the cut-rate shared hosters probably don't have the same level of management capabilities, but there are some out there that will let you do some really useful things (ie: ssh access, gcc, svn, cvs, php, ruby, python, mysql, etc, etc, etc). I guess one of their big gaps is with Postgres, I'd be interested if they had some of those management utilities available, but like it or not, most people and projects are MySQL specific.
I agree with the parent poster. Logical vs. Physical storage. For Physical, use SVN as it is easy and helpful. For logical, let me describe what I've generally seen-
Module => Project => Global
Do as much 'hack-hack-hack' as you want, but at the module (ie: login module, calculation module, reporting) levels... those might correspond to individual directories or individual files when you are working on your project. When you see an opportunity for re-use (hey, I'm always needing to build SQL strings in a certain way) then make that bit of extra effort to make those functions more generic and move them to the "project" level.
Always group things by "theme"... for PHP / JS, real "object oriented programming" is less useful, no matter what the purists say. Rule #1 about OOP is that you absolutely *DON'T* want to go down the path of relating Software Objects / Classes to Physical Objects. The example of a "class CAR has-a class STEERING_WHEEL which has-a class IGNITION_KEY" turns out to be just plain dumb. Group your functionality into useful chunks so that when you import those class/objects you can immediately start doing useful things with them. If you see that your "useful object" has two or three main themes, split those themes into separate classes and make that decision: do I make it shareable to more areas of my project.
After you've been doing this for a while, you'll start to see where the Global libraries come into place. Consider those things like PEAR or your own personal PEAR-equivalents. It requires more work, a slightly unnatural way of doing things at times, but exposes your work in a highly consistent manner for you to use in the future or other people as well.
Summary-
module-level: doing reporting... make some useful SQL functions
transition to shared SQL classes / functions for your whole project (re-org, re-write your original SQL functionality as necessary)
make that SQL functionality even more generic for you to re-use from proj. to proj. or so you can share it on a semi-global basis....and as a correspondence to this... don't be afraid to pull in stuff from "global-shared" (ie: PEAR, PHP-Classes) to get a head start (so long as you agree with the licenses)... that's why those things are out there in the first place, and how open source is supposed to work.:^)
I believe Mozilla needed cross-platform widgets around the 1999 timeframe (where it had already been under development for a year or two before I started using it). WayBack says:
1- Browser Theming / Skinning (see if you can find that recent slashdot link about Mozilla / FireFox history and marketing requirements).
2- Cross-Platform UI (Windows, Mac, Linux, etc)
3- CSS / Web styling on HTML buttons (http://www.4guysfromrolla.com/webtech/100601-1.sh tml)... probably would have been difficult with stock GTK (I think GTK uses system-wide themes rather than arbitrary themes generated on the fly from CSS per control per page
Once you've got to render buttons on web-pages with CSS 100% reliably anyway, and you add in that cross platform and themeable UI requirement, it's not that much of a stretch to add a Tab, Listbox, and Menu elements that can hook into your user interface. Yeah, it's kindof strange but it's helpful to remember the context of the time.
After watching the Apple market for a bit, Apple plays the retail game a little bit differently. You don't buy a "Pentium VII with 86gb of ram for $999", you buy a "$999 iBook". You don't "upgrade to a 15ghz Pentium X for $300 more", you buy a "$1299 iBook".
Basically, they abstract out *what* you are buying, assume that you will spend $1500, $2000, or $2500 and give you the best components, etc. that are available at those price points. RAM prices fall 90%? Great, they rev the boxes and you now get more RAM standard in the cheaper models. All component prices fall (processor, HD, video)? Now you get included WiFi and DVD burning as standard features, not options, or they improve screen sizes or something.
And they *never* run sales. Never. Base PowerBook is $1500 at store.apple.com, $1500 at Fry's $1500 at CompUSA (if they even sell them), basically, once you decide you want to buy a "PowerBook $1500", you go to the store, buy it, go home, and be happy. Even if you get "screwed" with $rev -1 hardware, you're basically just missing out on some extra ram, bigger hard drives, processor speed bump, some random hardware dongle (ie: WiFi, BlueTooth, DVD Burning)... which if you are "stupid" enough to not notice that when buying it, it won't matter anyway since all the included software works great on the laptop anyway and it's highly unlikely you're buying it so you can play the latest games.
From my interpretation of the state of things, now would be the "worst" time to buy any kind of PowerBook or iBook at full-retail, becuase it has been "out" the longest (the "most stale" hardware, probably the highest margins for apple), and is most likely to be replaced shortly (within the year) with different $999, $1299, $1499, $1999, $2499 models that have 80% more awesomeness or whatever new feature they're advertising.
I guess you've never spun a volume-control knob or a station dial before? Or moved a slider to change a setting? Even (as dumb as it is) patenting circle-forward, circle-backwards and sliding in an arbitrary direction would be a huge area covered. And due to it's "unique and inventive" use on a virtual touch-screen (since nobody has a consumer product out there that does that), it's potentially patentable.
My favorite patent example is the weed-whacker: It's not that glueing some plastic thread to an RC-Airplane engine is physically difficult... it's the "inventive" part that patents are supposed to protect (that fast-spinning thread attached to a motor cuts grass pretty well). Please don't paint me as a patent-lover, but don't automatically dismiss someone's claim of an inventive step because it seems obvious to you once you've seen it.
You give me paper, I'll give you your "Voting Brick(tm)". The point is that with paper (or caged gophers carving your votes into planks of wood), any recounts are very trustable and the security of physical items is a well-understood problem.
The point being that with any human-understandable, physical token serving as the official voting record, then the system(s) used to collect it are immaterial. Slap a hacked, virus-riddled, internet connected consumer PC into the voting booth and make me vote on it... if I get a paper receipt that I can read and understand and give that back to the election officials to serve as the vote of record, I'm OK with it. But give me a "Voting Brick(tm)" that says: "Your vote was cast. Click OK to continue."...somehow that doesn't give me the same warm-fuzzy.:^)
"""How do you recount? Election results must be reproduceable by a human afterwards, especially if a virus or spyware got into the election results (either on purpose, or with malicious intent). Open Voting has this part figured out by producing a paper ballot that can be validated without the use of a computer, or you can use a computer to check it faster."""
Their systems are reallly neat and they've had a lot of smart people looking at the problem. I've not been involved in it, but have read some of their documentations, and promised myself that I'd speak up and give them google-juice anytime voting came up. Some highlights:
- Commodity hardware / software
- Open source code
- Paper "receipts" that can be verified by:
* Sight
* Barcode
* Audio / Visual
* Separate "reader / recounter"
- Accurate computer counts (ie: select count(*) from votes group by person)
- Paper trail for recounts (re-count manually or computer assisted the receipts), with useful information hidden in the water-marked receipts (kindof like scantron stuff, where both computers and humans can read it)....all in all it seems like a pretty good system and like I said they've done a lot of thinking about it.
I can mostly agree with this. Untold hours of productivity when you only have a 486 laptop on the couch ssh'd into a remote machine and only basic cable (not expanded basic, you lucky ducks). Tunning full console since getting X even to come up was painfully slow (not that bad, but not that good, either. didn't help that the old laptop video card had buggy drivers).
Anyway, I broke down and got a powerbook when I couldn't do css/html development from the console without a GUI. Remarkably fat-free situation, and highly recommended that you try it sometime.
Unfortunately I can't find it right now, but I was recently reading something on Jacob Nielsen's use it about how yellow was a good attention-getting color. (it was something to do with in-page popups, and that yellow was the best background color).
Anyway, I'm guessing that is what the FF people were thinking when they first implemented it- basically that yellow is pretty well standardized as "look at me!" colors. However, after having a rational discussion with anybody in their right might, you should be able to see that IE7 has the right of it.
Stop lights? Green, Yellow, Red.
Stop sign? Red.
Checkmark / OK? Green.
Banking, shopping, money? Green.
IE / MS is opening up the game a bit more, rather than secure / insecure, they're talking about secure, phishing, and dunno-yet. And by doing that, it makes sense (FOR EVERYBODY, ESPECIALLY!) to follow those same standards if they're going to be playing the same game. Even if it means slight confusion in the short term it's worth it for the long-term benefits of standardization.
My (personal) experience is that doing testing while development is ongoing adds ~10-20% more time (not including find-fix for either tested or non-tested dev. methodologies).
When you add a find-fix cycle to either one (ie: prior to shipping to a customer), times can increase quite dramatically.
I would further state (in my experience) that find-fix cycles on code that does not have automated, repeatable tests (be they integration or unit)... the find fix cycles are larger and can cause more "trauma" if you have separate "finders" v. "fixers" (aka: QA v. Dev).
For example, consider the following histograms of time:
No Tests:
0123456789
Automated Tests (30% longer):
0123456789ABC
Including Find/Fix @ 4 points, no tests:
0123456789/FFFF
Including Find/Fix @ 2 points, automated tests:
0123456789ABC/FF
...These numbers are personal experience and could be way off, but it's interesting to map what's happening on the Automated Tests' "ABC" points. You're still developing, while "find/fix" is ongoing in the second no-test scenario... but my question is: Can you reliably release to your customer during the "FFFF" time-period with no tests? What about releasing to your customer during the "FF" time-period with automated tests?
Assuming that it's "easier to add a feature to code that has automated tests", let's add another feature to both...
Another feature, no tests @ 4 points:
0123456789/FFFF/FFFF
Another feature, automated tests @ 2 points:
0123456789ABC/FF/FF
...these are personal experiences, and make some assumptions, but I'd like to hear feedback from people who also have experience with automated testing (JUnit / NUnit, etc...) I think my numbers are right, but I'm interested in other perspectives too.
It's Not configuration of apache, but configuration of PHP. Basically, it's whether you allow the following:
[?php
$foo = `ls`;
$bar = include("http://foo.com/example.txt"); ?]
A lot of people have #1 (since they don't see the difficulty in allowing that, and in some cases it is hella-useful for hacking stuff together).
#2 is just plain dumb.
I don't remember what PHP ships with defaults nowadays (I think yes to shell commands at least), it's possible that they don't allow "http://" (remote file protocols) by default in their later releases.
Not configuration of apache, but configuration of PHP.
Basically, it's whether you allow the following:
A lot of people have #1 (since they don't see the difficulty in allowing that, and in some cases it is hella-useful).
#2 is just plain dumb.
I don't remember what PHP ships with defaults nowadays (I think yes to shell commands at least), it's possible that they don't allow "http://" (remote file protocols) in their later releases.
Excuse me for being contrarian (and I don't have all the links), but TFA's headline is a good example of what's wrong: "Google throws bodies at OpenOffice"
OpenOffice is not self-sustaining. It only exists because people are being paid to work on it. I believe a decent link is the following...
I am responsible for the StarOffice engineering and in this role also responsible for all engineering work on OpenOffice.org done by Sun employees. At the time of OpenOffice.org's inception I was responsible for StarOffice's base technology and involved in all the engineering discussions around open sourcing StarOffice. """
IANAOSOSC (I am Not an Open Source Office Software Contributor)... but contrast that statement with AbiWord, KOffice, Evolution, InkScape, etc. (AbiWord and KOffice both had their versions of kernel-traffic-like summaries which allowed me keep up with various development issues and see how their insides worked at one point or another. OpenOffice needing an FTE to manage other FTE's who are writing code is a recipe for "code because we tell you to".
It seems like certain types of companies exist solely to make the most complicated build processes, technology decisions, etc. This is as opposed to the OSS way of "Keep it Simple, Stupid"... when you start making it complex with $n+1 dependencies and steps the project either gets refactored or dies (and "Large(tm)" corporate invovlement generally has higher resistance to both the refactor and die options, as some areas seem to be personal vanity areas or have other political rather than technical motivations... aka: Java).
"""Building and hacking on OpenOffice.org (OO.o) entails climbing a fairly lengthy incline. Hopefully this document will make the learning curve somewhat steeper and more abrupt, and will give you a walking stick to help you out."""
Which isn't to say that having somebody "big" like Sun behind an office suite is all bad. It's because of them that we have the clippy-like thing, the chm-like thing, the templates, wizards, import filters, and all the other mostly boring "feature checkboxes" that we do now in OO.o.
If I could wave my magic wand and have everything the way that I want, I'd split out the OO input filters (seem to get really good reviews and good personal results). Kill the really-tight integration between Presenter, Writer, Drawer, etc... (although if that's the way MSOffice handles embedded tables, etc., maybe it's a necessary evil?). And a healthy helping of de-cruftify, especially the preferences panels. Maybe a FireFox-like project to strip down OpenOffice would be helpful.
What's the issue? Remember: GPL sez: "If I give you binaries, I have to give you code. If I give you code, I can't stop you from giving other people the code."
CrazyUnixHippie: sets up CrazyUnixHippie.org and gives away source / binaries.
Until #2 happens, don't worry that #3 hasn't happened yet. Please don't pick on my incorrect use of Trademarks in an example about GPL rights, don't confuse the fledgeling hackers out there.
--Robert
Re:How do you do a character literal?
on
Vim 6.4 Released
·
· Score: 1
You're in "windows compatible mode" (mswin)... some of it is nice, some of it is total luser. I usually turn it off, but it means that I don't get "ctrl-v" for paste, I have to remember: "+p... but once you get used to it it's not that bad!;^)
I like the presentation of it all, just remember: "If you figure it out, you don't want to give the idea away to these other jokers around you. Make them work for the answers, too."
The goal was to record browser-interactions against a web-page with GreaseMonkey (as snippets of executable python), then "save" the actions to an internal wiki under a name chosen by the user.
If the functions had args 'def func( arg1="foo", arg2="bar" )' then prompt for a value (providing defaults) whenever that action was added to the end-script via a wizard.
Each function is then documented via wiki ("The FooSearch function is used when blah blah blah"), you get search, version control, etc for free (and users are mostly ok using wiki here anyway) and documentation and functionality is user-created in an environment that the users are mostly comfortable with anyway.
So the use-model was:
install greasemonkey / record plugin click record in firefox do actions in browser click save to "function-name / wiki-name" go to "wiki-wizard" generate script with prompts / popups click "execute" button profit!
...for a variety of reasons (mostly that GUI automation tools are expensive / difficult to integrate into other things) I didn't get too much farther with it, but it definitely worked as a proof of concept. This gets back to another thought of mine... "Open Source" can only be successful if the "Source" part is at the right level of abstraction.
Writing an open-source mail client in assembly isn't really open source (users can't really edit it).
Writing an open-source mail client in c/c++ is better, but only for techy people (smart users can edit it).
Writing an open-source mail client in python is the best, since ideally your users can jump down "just one level" and do some useful stuff with some simple python.
Witness FireFox. The C/C++ render-goodies aren't as "Open Source" as XPI / XUL / GreaseMonkey. By making the barrier to entry lower and lower, you're opening the source to more and more people (at least at the simple level) which is a good thing.
...the basic premise being that each function gets stuck onto it's own wiki page (def foo()...), wiki provides the equivalent of CVS, and with Python I basically wrote a new "import" function that imports code on the fly in about 20 lines of code.
Before going farther with this, read up on Knuth's "Literate Programming" ideas. Also, take off your "programmer's goggles" and put on your "not an expert programmer's" goggles. With a sufficient level of abstraction, and good whip-cracking on the architecture to keep most complicated stuff "out of sight", non-programmers can pretty effectively build software out of componentized pieces. They can even build some component pieces themselves if they're motivated and can understand what's going on. And once it's in a wiki hidden between [code] blocks, lean on the wiki to provide gooood documentation (think wikipedia, but with little blocks of code).
I've had an idea kicking around for a while now... "HDFS / Home-Dir File System"... I want a (s)low-performance, bloated, version controlled, roll-back featured, viewcvs.cgi enabled file system for my/home/rames (or at least/home/rames/documents).
With FUSE it might even be possible for mere mortals like me.
Basically, I very rarely push more around more than 100-200kb at a time of "my stuff" unless it's big OGG's or tgz's, etc. Mostly source files, documents, resume's, etc. In that case, I want to be able to go historical to any saved revision *at the file-system level*, kindof like "always on cvs / svn / (git?)" for certain directories. Then when I accidently nuke files or make mistakes or whatever, I can drag a slider in a GUI and "roll-back" my filesystem to a certain point in time and bring that saved state into the present.
Performance is not an issue (at first), as I'm OK if my files take 3 seconds to save in vim or OpenOffice instead of 0.5 seconds. Space is not an issue because I don't generally revise Large(tm) files (and it would be pretty straightforward to have a MaxLimit size for any particular file). Maintenance would also be pretty straighforward: crontab "@daily dump revisions > 1 month". Include some special logic for "if a file is changing a lot, only snapshot versions every 5-10 minutes" and you could even handle some of the larger stuff like images without too much work.
Having done quite a bit of reading of KernelTraffic (Hi Zack) and recently about GIT, maybe it's time to dust off some python and C and see what happens...
Slashdot Mirror
Reminds me of when we tried to play Super Dance Dance Fighter 2 Turbo. Basically Street Fighter but too lazy to undo the dance pads. Damned bastard picked Guile and just did Sonic Booms or Flash Kicks while I was stuck trying to do Kens Dragon Punch or Hurricane Kick. I learned my lesson, though- next match I picked Blanca...
--Robert
This is different from:
So one half of it is tech, the other half is collaboration, the other half is api's.
--Robert
As an aside...
So what if you have some reasonably complicated website with login, "stuff" and everything else, and you want to integrate some sort of message-board?
I've been working on a games website with a friend, where step #1 was "make games work". Now we're on step 3 or 4, which is "get forum software", but I haven't found any relevant sites discussing integrating some reasonably simple forum software with existing login systems.
There seems to be two schools of thought:
1- You are an end-user and "just want some discussion software, dammit", which is admittedly a large part of the market.
2- There is no two!
The well known software projects (phpBB, drupal, etc) all have a significant portion of user-management stuff, which I already have (and don't want!) due to the work that we've done on the main portion of the site.
My ideal would be some discussion software where I could override a "is_logged_in" function, and maybe a "link_to_profile" function and it provided all the rest of everything else.
Second place would go to some software where I could (easily!) create new forum users automatically and sync username / password changes pretty easily. It would be sub-optimal, but "ok" if users had to log in to the main site, and / or log in to the forum (ie: two separate cookies / login instances), but it's better than wasting time writting yet another forum / polling software thingy.
Lastly would be to rewrite all of "my" code to be based on the forum login / profile / identity stuff, but that's a huge PITA too...
Any recommendations or experiences? (would this make a good ask slashdot?)
--Robert
I don't know jack about PCB design, but wouldn't the internet qualify? :^)
--Robert
--Robert
I agree with the parent poster. Logical vs. Physical storage. For Physical, use SVN as it is easy and helpful. For logical, let me describe what I've generally seen-
... for PHP / JS, real "object oriented programming" is less useful, no matter what the purists say. Rule #1 about OOP is that you absolutely *DON'T* want to go down the path of relating Software Objects / Classes to Physical Objects. The example of a "class CAR has-a class STEERING_WHEEL which has-a class IGNITION_KEY" turns out to be just plain dumb. Group your functionality into useful chunks so that when you import those class/objects you can immediately start doing useful things with them. If you see that your "useful object" has two or three main themes, split those themes into separate classes and make that decision: do I make it shareable to more areas of my project.
...and as a correspondence to this... don't be afraid to pull in stuff from "global-shared" (ie: PEAR, PHP-Classes) to get a head start (so long as you agree with the licenses)... that's why those things are out there in the first place, and how open source is supposed to work. :^)
Module => Project => Global
Do as much 'hack-hack-hack' as you want, but at the module (ie: login module, calculation module, reporting) levels... those might correspond to individual directories or individual files when you are working on your project. When you see an opportunity for re-use (hey, I'm always needing to build SQL strings in a certain way) then make that bit of extra effort to make those functions more generic and move them to the "project" level.
Always group things by "theme"
After you've been doing this for a while, you'll start to see where the Global libraries come into place. Consider those things like PEAR or your own personal PEAR-equivalents. It requires more work, a slightly unnatural way of doing things at times, but exposes your work in a highly consistent manner for you to use in the future or other people as well.
Summary-
module-level: doing reporting... make some useful SQL functions
transition to shared SQL classes / functions for your whole project
(re-org, re-write your original SQL functionality as necessary)
make that SQL functionality even more generic for you to re-use from proj. to proj. or so you can share it on a semi-global basis.
--Robert
I believe Mozilla needed cross-platform widgets around the 1999 timeframe (where it had already been under development for a year or two before I started using it). WayBack says:
. org/announce.html
...which theoretically shows that Gimp was working on Win32 at the time although probably not landed in the existing GTK Branches. (http://web.archive.org/web/19990202104158/user.sg ic.fi/~tml/gimp/win32/)
h tml) ... probably would have been difficult with stock GTK (I think GTK uses system-wide themes rather than arbitrary themes generated on the fly from CSS per control per page
http://web.archive.org/web/19990508065645/www.gtk
"""GTK+ is also being ported to Win32. For further information see: http://www.iki.fi/tml/gimp/win32/."""
But keep in mind a few other requirements:
1- Browser Theming / Skinning (see if you can find that recent slashdot link about Mozilla / FireFox history and marketing requirements).
2- Cross-Platform UI (Windows, Mac, Linux, etc)
3- CSS / Web styling on HTML buttons (http://www.4guysfromrolla.com/webtech/100601-1.s
Once you've got to render buttons on web-pages with CSS 100% reliably anyway, and you add in that cross platform and themeable UI requirement, it's not that much of a stretch to add a Tab, Listbox, and Menu elements that can hook into your user interface. Yeah, it's kindof strange but it's helpful to remember the context of the time.
--Robert
After watching the Apple market for a bit, Apple plays the retail game a little bit differently. You don't buy a "Pentium VII with 86gb of ram for $999", you buy a "$999 iBook". You don't "upgrade to a 15ghz Pentium X for $300 more", you buy a "$1299 iBook".
... which if you are "stupid" enough to not notice that when buying it, it won't matter anyway since all the included software works great on the laptop anyway and it's highly unlikely you're buying it so you can play the latest games.
Basically, they abstract out *what* you are buying, assume that you will spend $1500, $2000, or $2500 and give you the best components, etc. that are available at those price points. RAM prices fall 90%? Great, they rev the boxes and you now get more RAM standard in the cheaper models. All component prices fall (processor, HD, video)? Now you get included WiFi and DVD burning as standard features, not options, or they improve screen sizes or something.
And they *never* run sales. Never. Base PowerBook is $1500 at store.apple.com, $1500 at Fry's $1500 at CompUSA (if they even sell them), basically, once you decide you want to buy a "PowerBook $1500", you go to the store, buy it, go home, and be happy. Even if you get "screwed" with $rev -1 hardware, you're basically just missing out on some extra ram, bigger hard drives, processor speed bump, some random hardware dongle (ie: WiFi, BlueTooth, DVD Burning)
From my interpretation of the state of things, now would be the "worst" time to buy any kind of PowerBook or iBook at full-retail, becuase it has been "out" the longest (the "most stale" hardware, probably the highest margins for apple), and is most likely to be replaced shortly (within the year) with different $999, $1299, $1499, $1999, $2499 models that have 80% more awesomeness or whatever new feature they're advertising.
--Robert
I guess you've never spun a volume-control knob or a station dial before? Or moved a slider to change a setting? Even (as dumb as it is) patenting circle-forward, circle-backwards and sliding in an arbitrary direction would be a huge area covered. And due to it's "unique and inventive" use on a virtual touch-screen (since nobody has a consumer product out there that does that), it's potentially patentable.
My favorite patent example is the weed-whacker: It's not that glueing some plastic thread to an RC-Airplane engine is physically difficult... it's the "inventive" part that patents are supposed to protect (that fast-spinning thread attached to a motor cuts grass pretty well). Please don't paint me as a patent-lover, but don't automatically dismiss someone's claim of an inventive step because it seems obvious to you once you've seen it.
--Robert
You give me paper, I'll give you your "Voting Brick(tm)". The point is that with paper (or caged gophers carving your votes into planks of wood), any recounts are very trustable and the security of physical items is a well-understood problem.
...somehow that doesn't give me the same warm-fuzzy. :^)
The point being that with any human-understandable, physical token serving as the official voting record, then the system(s) used to collect it are immaterial. Slap a hacked, virus-riddled, internet connected consumer PC into the voting booth and make me vote on it... if I get a paper receipt that I can read and understand and give that back to the election officials to serve as the vote of record, I'm OK with it. But give me a "Voting Brick(tm)" that says: "Your vote was cast. Click OK to continue."
--Robert
"""How do you recount? Election results must be reproduceable by a human afterwards, especially if a virus or spyware got into the election results (either on purpose, or with malicious intent). Open Voting has this part figured out by producing a paper ballot that can be validated without the use of a computer, or you can use a computer to check it faster."""
v ote-hacking-2004.html
a me=FAQ&myfaq=yes&id_cat=11&categories=Security%2C+ Resiliency%2C+Integrity%2C+Reliability
...all in all it seems like a pretty good system and like I said they've done a lot of thinking about it.
http://www.robertames.com/blog.cgi/entries/links/
Links have broken with time, but here's an updated link to Open Voting...
http://www.openvotingconsortium.org/modules.php?n
Their systems are reallly neat and they've had a lot of smart people looking at the problem. I've not been involved in it, but have read some of their documentations, and promised myself that I'd speak up and give them google-juice anytime voting came up. Some highlights:
- Commodity hardware / software
- Open source code
- Paper "receipts" that can be verified by:
* Sight
* Barcode
* Audio / Visual
* Separate "reader / recounter"
- Accurate computer counts (ie: select count(*) from votes group by person)
- Paper trail for recounts (re-count manually or computer assisted the receipts), with useful information hidden in the water-marked receipts (kindof like scantron stuff, where both computers and humans can read it).
--Robert
I can mostly agree with this. Untold hours of productivity when you only have a 486 laptop on the couch ssh'd into a remote machine and only basic cable (not expanded basic, you lucky ducks). Tunning full console since getting X even to come up was painfully slow (not that bad, but not that good, either. didn't help that the old laptop video card had buggy drivers).
Anyway, I broke down and got a powerbook when I couldn't do css/html development from the console without a GUI. Remarkably fat-free situation, and highly recommended that you try it sometime.
--Robert
Unfortunately I can't find it right now, but I was recently reading something on Jacob Nielsen's use it about how yellow was a good attention-getting color. (it was something to do with in-page popups, and that yellow was the best background color).
Anyway, I'm guessing that is what the FF people were thinking when they first implemented it- basically that yellow is pretty well standardized as "look at me!" colors. However, after having a rational discussion with anybody in their right might, you should be able to see that IE7 has the right of it.
Stop lights? Green, Yellow, Red.
Stop sign? Red.
Checkmark / OK? Green.
Banking, shopping, money? Green.
IE / MS is opening up the game a bit more, rather than secure / insecure, they're talking about secure, phishing, and dunno-yet. And by doing that, it makes sense (FOR EVERYBODY, ESPECIALLY!) to follow those same standards if they're going to be playing the same game. Even if it means slight confusion in the short term it's worth it for the long-term benefits of standardization.
--Robert
...they were all trying for First Post.
--Robert
My (personal) experience is that doing testing while development is ongoing adds ~10-20% more time (not including find-fix for either tested or non-tested dev. methodologies).
... the find fix cycles are larger and can cause more "trauma" if you have separate "finders" v. "fixers" (aka: QA v. Dev).
When you add a find-fix cycle to either one (ie: prior to shipping to a customer), times can increase quite dramatically.
I would further state (in my experience) that find-fix cycles on code that does not have automated, repeatable tests (be they integration or unit)
For example, consider the following histograms of time:
No Tests:
0123456789
Automated Tests (30% longer):
0123456789ABC
Including Find/Fix @ 4 points, no tests:
0123456789/FFFF
Including Find/Fix @ 2 points, automated tests:
0123456789ABC/FF
...These numbers are personal experience and could be way off, but it's interesting to map what's happening on the Automated Tests' "ABC" points. You're still developing, while "find/fix" is ongoing in the second no-test scenario... but my question is: Can you reliably release to your customer during the "FFFF" time-period with no tests? What about releasing to your customer during the "FF" time-period with automated tests?
Assuming that it's "easier to add a feature to code that has automated tests", let's add another feature to both...
Another feature, no tests @ 4 points:
0123456789/FFFF/FFFF
Another feature, automated tests @ 2 points:
0123456789ABC/FF/FF
...these are personal experiences, and make some assumptions, but I'd like to hear feedback from people who also have experience with automated testing (JUnit / NUnit, etc...) I think my numbers are right, but I'm interested in other perspectives too.
--Robert
Damned slashdot eats my code examples. Re-post.
It's Not configuration of apache, but configuration of PHP. Basically, it's whether you allow the following:
[?php
$foo = `ls`;
$bar = include("http://foo.com/example.txt");
?]
A lot of people have #1 (since they don't see the difficulty in allowing that, and in some cases it is hella-useful for hacking stuff together).
#2 is just plain dumb.
I don't remember what PHP ships with defaults nowadays (I think yes to shell commands at least), it's possible that they don't allow "http://" (remote file protocols) by default in their later releases.
--Robert
Not configuration of apache, but configuration of PHP.
Basically, it's whether you allow the following:
A lot of people have #1 (since they don't see the difficulty in allowing that, and in some cases it is hella-useful).
#2 is just plain dumb.
I don't remember what PHP ships with defaults nowadays (I think yes to shell commands at least), it's possible that they don't allow "http://" (remote file protocols) in their later releases.
--Robert
Excuse me for being contrarian (and I don't have all the links), but TFA's headline is a good example of what's wrong: "Google throws bodies at OpenOffice"
r g_heilig.html:
... when you start making it complex with $n+1 dependencies and steps the project either gets refactored or dies (and "Large(tm)" corporate invovlement generally has higher resistance to both the refactor and die options, as some areas seem to be personal vanity areas or have other political rather than technical motivations ... aka: Java).
OpenOffice is not self-sustaining. It only exists because people are being paid to work on it. I believe a decent link is the following...
http://www.openoffice.org/editorial/interview_joe
"""What is your role now in OpenOffice.org/StarOffice and what was your role in architecting the OpenOffice.org project at its inception?
I am responsible for the StarOffice engineering and in this role also responsible for all engineering work on OpenOffice.org done by Sun employees. At the time of OpenOffice.org's inception I was responsible for StarOffice's base technology and involved in all the engineering discussions around open sourcing StarOffice. """
IANAOSOSC (I am Not an Open Source Office Software Contributor)... but contrast that statement with AbiWord, KOffice, Evolution, InkScape, etc. (AbiWord and KOffice both had their versions of kernel-traffic-like summaries which allowed me keep up with various development issues and see how their insides worked at one point or another. OpenOffice needing an FTE to manage other FTE's who are writing code is a recipe for "code because we tell you to".
It seems like certain types of companies exist solely to make the most complicated build processes, technology decisions, etc. This is as opposed to the OSS way of "Keep it Simple, Stupid"
http://ooo.ximian.com/hackers-guide.html:
"""Building and hacking on OpenOffice.org (OO.o) entails climbing a fairly lengthy incline. Hopefully this document will make the learning curve somewhat steeper and more abrupt, and will give you a walking stick to help you out."""
Which isn't to say that having somebody "big" like Sun behind an office suite is all bad. It's because of them that we have the clippy-like thing, the chm-like thing, the templates, wizards, import filters, and all the other mostly boring "feature checkboxes" that we do now in OO.o.
If I could wave my magic wand and have everything the way that I want, I'd split out the OO input filters (seem to get really good reviews and good personal results). Kill the really-tight integration between Presenter, Writer, Drawer, etc... (although if that's the way MSOffice handles embedded tables, etc., maybe it's a necessary evil?). And a healthy helping of de-cruftify, especially the preferences panels. Maybe a FireFox-like project to strip down OpenOffice would be helpful.
Just my outsider's perspective....
--Robert
...http://www.drdos.com/products/sourcecode.htm
???
What's the issue? Remember: GPL sez: "If I give you binaries, I have to give you code. If I give you code, I can't stop you from giving other people the code."
For the license illiterate out there:
Microsoft.com: Sells you "GPL FireFox" for $100.
CrazyUnixHippie: Buys "GPL FireFox", requests source code.
CrazyUnixHippie: sets up CrazyUnixHippie.org and gives away source / binaries.
Until #2 happens, don't worry that #3 hasn't happened yet. Please don't pick on my incorrect use of Trademarks in an example about GPL rights, don't confuse the fledgeling hackers out there.
--Robert
You're in "windows compatible mode" (mswin) ... some of it is nice, some of it is total luser. I usually turn it off, but it means that I don't get "ctrl-v" for paste, I have to remember: "+p ... but once you get used to it it's not that bad! ;^)
--Robert
Sharing with all my slashdot friends:
When I saw the original article, I snagged the text and implemented a version of petals around the rose.
I like the presentation of it all, just remember: "If you figure it out, you don't want to give the idea away to these other jokers around you. Make them work for the answers, too."
--Robert
The goal was to record browser-interactions against a web-page with GreaseMonkey (as snippets of executable python), then "save" the actions to an internal wiki under a name chosen by the user.
def UserDefinedFunctionNameForSearching():
browser.useForm( "search" )
browser.set( "q", "test something" )
browser.submit()
...then let users string together these functions into executeable scripts via a simple wizard:
Execute( "UserDefinedFunctionSearching" )
Execute( "UserDefinedFunctionSelect", foo='123', bar='test' )
Execute( "UserDefinedFunctionValidate" )
If the functions had args 'def func( arg1="foo", arg2="bar" )' then prompt for a value (providing defaults) whenever that action was added to the end-script via a wizard.
Each function is then documented via wiki ("The FooSearch function is used when blah blah blah"), you get search, version control, etc for free (and users are mostly ok using wiki here anyway) and documentation and functionality is user-created in an environment that the users are mostly comfortable with anyway.
So the use-model was:
install greasemonkey / record plugin
click record in firefox
do actions in browser
click save to "function-name / wiki-name"
go to "wiki-wizard"
generate script with prompts / popups
click "execute" button
profit!
...for a variety of reasons (mostly that GUI automation tools are expensive / difficult to integrate into other things) I didn't get too much farther with it, but it definitely worked as a proof of concept. This gets back to another thought of mine... "Open Source" can only be successful if the "Source" part is at the right level of abstraction.
Writing an open-source mail client in assembly isn't really open source (users can't really edit it).
Writing an open-source mail client in c/c++ is better, but only for techy people (smart users can edit it).
Writing an open-source mail client in python is the best, since ideally your users can jump down "just one level" and do some useful stuff with some simple python.
Witness FireFox. The C/C++ render-goodies aren't as "Open Source" as XPI / XUL / GreaseMonkey. By making the barrier to entry lower and lower, you're opening the source to more and more people (at least at the simple level) which is a good thing.
--Robert
I did something similar to this at work... some greasemonkey scripts wired to a wiki as a backend datastore with some extra popup helper dialogs.
You would then run it via Python's great runtime eval stuff. Since I'm pretty tired, maybe some code would help demonstrate:
def Import( wikiword ):
print ">>> Importing: " + wikiword
text = getTextFromWikiWord( wikiword )
code = getCodeFromText( text )
if len( code ) == 0:
raise "No Code Found For: " + wikiword
exec code in globals()
return
def getTextFromWikiWord():
# you can do some sort of HTTP fetch or file.open here
def getCodeFromText():
# this basically grep's for [code]...[/code] blocks
# and smushes them together
def Execute( wikiword, **params ):
print ">>> Executing: " + wikiword
Import( wikiword )
str = wikiword +"( **params )"
eval( str )
return
if __name__ == '__main__':
Execute( sys.argv[1] )
...the basic premise being that each function gets stuck onto it's own wiki page (def foo()...), wiki provides the equivalent of CVS, and with Python I basically wrote a new "import" function that imports code on the fly in about 20 lines of code.
Before going farther with this, read up on Knuth's "Literate Programming" ideas. Also, take off your "programmer's goggles" and put on your "not an expert programmer's" goggles. With a sufficient level of abstraction, and good whip-cracking on the architecture to keep most complicated stuff "out of sight", non-programmers can pretty effectively build software out of componentized pieces. They can even build some component pieces themselves if they're motivated and can understand what's going on. And once it's in a wiki hidden between [code] blocks, lean on the wiki to provide gooood documentation (think wikipedia, but with little blocks of code).
--Robert
Thanks for the links! ... Gotta love the Time-Travelling File Manager!
--Robert
I've had an idea kicking around for a while now... "HDFS / Home-Dir File System" ... I want a (s)low-performance, bloated, version controlled, roll-back featured, viewcvs.cgi enabled file system for my /home/rames (or at least /home/rames/documents).
With FUSE it might even be possible for mere mortals like me.
Basically, I very rarely push more around more than 100-200kb at a time of "my stuff" unless it's big OGG's or tgz's, etc. Mostly source files, documents, resume's, etc. In that case, I want to be able to go historical to any saved revision *at the file-system level*, kindof like "always on cvs / svn / (git?)" for certain directories. Then when I accidently nuke files or make mistakes or whatever, I can drag a slider in a GUI and "roll-back" my filesystem to a certain point in time and bring that saved state into the present.
Performance is not an issue (at first), as I'm OK if my files take 3 seconds to save in vim or OpenOffice instead of 0.5 seconds. Space is not an issue because I don't generally revise Large(tm) files (and it would be pretty straightforward to have a MaxLimit size for any particular file). Maintenance would also be pretty straighforward: crontab "@daily dump revisions > 1 month". Include some special logic for "if a file is changing a lot, only snapshot versions every 5-10 minutes" and you could even handle some of the larger stuff like images without too much work.
Having done quite a bit of reading of KernelTraffic (Hi Zack) and recently about GIT, maybe it's time to dust off some python and C and see what happens...
--Robert