Re:Those who read it area already clued in
on
Managing Einsteins
·
· Score: 1
... and then there are the managers out there who might read this book, assuming they knew it even existed. Managers who would be willing to accept help from others in improving their management skills. Concept, huh?
All generalizations are inaccurate -- including this one.;-)
For a PDF from Apple on NetInfo, check out UnderstandingUsingNetInfo.pdf. I've looked it over, haven't read it yet, it seems to be a pretty decent intro.
Mike, the flip side of your last paragraph is somewhat more useful. I've used TogetherControlCenter to create class diagrams visually. The program generates (in my case, Java) code for each of those classes. Admittedly skeleton code, but it allows me to go from package/class design directly into fulfilling the contract laid down by the design. I've only used the "Community" version, so I have not had access to the other UML diagram types, but (according to the readme and help files) the other diagrams take the classes from the class diagram and add more code based on the other diagrams.
Bluntly, it is loads faster for me as an "all-in-one" analyst/designer/developer for me to do the design in such a UML diagrammer/code generation tool, then flesh out the rest of the code afterwards. For people who work in separate roles, if the analysts and designers are worth their paycheck as professional communicators, then they should be able to hand a coder a written specification that allows the coder to work just as quickly.
And, as to your original statement, Rational can indeed generate UML from code -- and then allow the user to manipulate the UML and thus generate new code.
At the base level, some people work well visually, and some don't. Those who work well visually and understand code and know their tools can use "proper" UML tools to make their lives much, much easier.
Idiot, read the article first. The new protocol takes care of latency, timing issues, packet collisions, etc. Did you honestly think that Gibson would be stupid enough to release something that doesn't address the fundamental flaws of Ethernet in regards to the problem domain?
Seriously, if you have to type in the problem and the fix, it isn't going to kill you to type in an asset code or something. As a hint, if you're not using Dells (with their nifty little ID tags), and you want to avoid the pain of having to type in the full serial number each time, put together a table in your database where you have all the serial numbers of your items (type once), then link it to a short asset number. Get a label maker, put label on item. When item comes through your door, type in the asset number, and be done with it.
The pain and hassle of acquiring (relatively) expensive barcode readers and coding up the necessary software more than likely outweighs the pain and hassle of having to type in a serial number once and an asset number multiple times -- ESPECIALLY if you have to type anyway. The only time that barcoding is really worth it is if it can save you LARGE amounts of typing time. Normally, it can't. You will have to think long and hard about the ability of barcoding to automate work processes.
An example of the above is inventory: you can scan in the barcode of the item you are checking in, scan in the code of the shelf, scan in the bin/box/whatever, and your app will track where you put something. Great, right? Another real world example: a nurse scans the barcode of the patient's wristband, scans the barcode of the drug she has, and the app checks to see that the drug is indeed the one prescribed for this patient, and throws a warning if it isn't or if the dosage is incorrect. If it *is* the correct prescription and patient, the nurse dispenses the drug, then scans her *own* barcode, and the hospital information system records that the drug was dispensed by the nurse to the patient. The first application might be relatively easy to code; the second one is not.
The real question you should be asking yourself is whether you can automate your process so that you can achieve the same level of functionality without typing. When it comes to describing problems and resolutions, I don't think you can. Maybe you can create a list of barcodes for your common problems, and a list of codes for your normal resolutions, and automate that way -- but remember to make sure that the exceptions (when they inevitably happen) are not so hard to use that it's not more work than it is worth.
As another commenter pointed out, look at existing handhelds. It seems to me that what you want is a more-or-less fullsize keyboard and screen for something like the new Sharp Zaurus Linux PDA. So, instead of going nuts trying to build a laptop from scratch (neat idea, but WAY impractical IMHO), try finding or building or commissioning an expansion part: an adapter to whatever expansion slots exist on the Sharp or iPaq, which provides a USB controller and 2 ports (keyboard and mouse), and provides some sort of basic video out. As an alternative, a new cradle that has a built-in keyboard, trackpad, LCD screen and Ethernet port. Let the cradle have its own built-in battery (I hear fuel-cell technology is up-and-coming), and there you go. Add extra storage to taste (flash?), and you would really have something.
In fact, I'd buy something like that in a heart-beat. In all honesty, a gadget like this, truly well-designed and built, would make a good Linux-based hand-held into a truly killer device. Laptop manufacturers would be running scared!
I, too, have a BA in philosophy. My career in computers began quite a while ago (I'm 29 now), when I was in college. Like others who have posted, I got a job with the college's computer support group, where I learned basic troubleshooting for DOS, Windows 3.1, and Mac OS 6+. I enjoyed fixing things, so I pestered the hardware guy for a bit, and he took me under his wing and made me the junior repair person. By my last year there, I was managing the student workers. While I was there, I had no exposure to Unix at all; instead, we had a VAX/VMS that we students were never allowed to touch except as users, and all networking was DECnet and was also the domain of experts/full-time staff.
I took a year off from school, and parlayed my experience into full-time jobs doing tech support -- one on a contract, the other at a company that went Chapter 11 and got dissolved (anybody remember Dove modems for Macs?:). Anyway, my year up I went back to school and graduated.
After graduation, I got another contract job, working for (dons flame-retardant long-johns) Microsoft, doing telephone tech support for Word and Windows 95. They gave us some pretty amazing training before letting us loose on the phones... then some bean-counter came on board as a VP, and decided to make his mark on the bottom line by eliminating as many contractors as possible.
After that, I went through a series of short-term contract jobs, then got a permanent job as tech support/project manager/computer trainer for a (very) small hospital. That was my first exposure to NT administration. I had another brief stint at contracting after 18 months at the hospital, and am now working (for the past three years) at a much larger hospital as the "network administrator" for a particular department.
I've been here for 2.5 years now, and have not done much network admin in Windows; our centralized IS department keeps the servers. I've done tons of tech support, and worked my way through a certificate program in Java & Oracle development, taught myself VBA and built some Access databases, and got myself promoted. Now I do database programming (currently working on a home-grown lab management system using PostgreSQL and Tomcat), and have been introduced to Unix in a neat way -- we are a research department, and we hired a statistical geneticist. He brought with him a couple of Sun Ultra 10's, and the department shipped me off for Solaris training in order to support him. We expanded the number of machines, and have been installing FreeBSD on our standard Compaq desktops, and running Linux on one Alpha machine and Tru64 on the other.
The statistician introduced me to O'Reilly, and I've been reading like crazy and practicing on the side, constantly learning (Python at the moment).
So now I have a very wide range of skills, and a fair bit of depth in a couple of different areas. I'm not a full-time Unix sysadmin, but I probably would qualify for a jr. level sysadmin job somewhere. I'm not a full-time Java programmer, but would probably do pretty well in a junior-to-mid level position.
We faced a similar problem, and the answer is ugly, but simple: Oracle doesn't work on Linux for Alpha.
We originally bought an Atipa Linux Alpha machine running Tru64, with the intent of running Oracle on it. We specced it out with an internal RAID controller and three U160 SCSI 10k (or is it 15, I forget...) drives. When we got the machine, we found out that Atipa had substituted a different RAID card, because the one originally specified (128 MB cache, 3 channels, whiz-bang...) wasn't supported under Tru64. In fact, on our system, the only card supported is a measly 4MB cache, single-channel card. We were seeing approx 6MB/second throughput using RAID 5.
Needless to say, we were not happy.
Long story short, after much runaround, they sold us the card we had specced *AT 1/3 THE PRICE OF THE COMPAQ CARD*, and we installed Linux instead. We now get ~45MB/second sustained throughput under RAID 5. Then we found that Oracle doesn't work/hasn't been tested on Linux for Alpha. In the end, we are using PostgreSQL, and are quite happy with it. But, our database is relatively small and has few connections -- it's used to mirror the BLAST databases for internal research.
My understanding (pass along as rumor, but from the CNET article, MacSlash, etc., so it may have *some* slight credibility) is that the retailers (Apple Stores, CompUSA, whatever) will hand out CDs both of the update itself and the updated developer tools CD.
The devtools CD is also supposed to be in the retail 10.1 box.
Okay, agreed that Jakarta is cool -- BUT. You missed the point in a big way, and you have a glaring error of fact in your comment.
Tomcat is excellent, but there is no such thing as a J2EE servlet engine, and you characterizing it as such is doing both Tomcat and Ganesh's article a disservice. The fact is that a servlet/JSP engine is a cool deal, but by itself it is not J2EE, and doesn't bring with it all the benefits that J2EE brings. Yes, servlets/JSPs are cool, but they are, at heart, part of the presentation layer of an n-tier architecture. If the world needs an enterprise-class solution, with clustering, redundancy, scalability, five 9s, they can't do it with Tomcat, at least by itself. Servlets are cool, yes, but Tomcat as a servlet engine doesn't have what it takes to handle enterprise-level requirements of stability, clustering, etc.
The point that Ganesh was attempting to make was that the OSS community at large needs to wake up from our communal head-in-the-sand attitude about Java and J2EE, and realize that aside from Java there really aren't a whole lot of options for enterprise-level stuff.
(Zope provides one option, but the documentation was horrendous last I looked, and Zope was not easy to configure as an experiment. The "roll yer own, it's all open standards" folks also have a valid point, but businesses seek productivity *gains* by reusing existing, known-good frameworks rather than being forced into productivity *losses* because you have to write your own framework first.)
Web services is really only the communication layer, and really only the automated communication layer -- but that's a very important layer. Yet still, the underlying business-class functionality (in other words, the services a business has to offer the world), is what's important, and Microsoft has done a pretty darn good job with marketspeak and packaging, and has begun selling an end-to-end solution, a solution that promises M$ domination on the back-end to the same degree as on the desktop.
And that is Ganesh's point: we need to either write our own enterprise-level component-based web services soup-to-nuts framework, or we need to unite behind an existing framework (Java, J2EE), or we will wind up suffocating in M$ products all the way around.
Tomcat itself is irrelevant, except as a (vital) component of the existing alternative architecture. And you'll notice that, of the major servlet engine vendors, pretty much all of them now sell J2EE containers that incorporate their prior servlet engine -- Weblogic, Websphere, JRUN... And one notable database vendor (another major part of the enterprise computing framework) has decided to enter the same marketspace with their own offering: Oracle's 9iAS.
PDF Virus a *Proof of Concept*, not a real threat
on
PDF Virus Spotted
·
· Score: 3, Interesting
As many have already noted, the embedded VBScript will only run when triggered by someone double-clicking on the file annotation included in the PDF while using the full version of Acrobat. Thus, the virus is not particularly dangerous.
The social engineering, however, is pretty amazing. The author has created a neat little PDF "game" that people will want to double-click. And, as he wrote in the text file linked above, he wrote it as a proof of concept. The worm doesn't do much except spread itself using Outlook. I think the scary part, the point the author wanted to make, is that you can embed all sorts of fun things in a PDF file. Some other virus writer could make a new version that does something nasty after it emails itself to every address it can find in your Outlook folders.
Yes, the threat level is low, due to the required combination of software and social engineering. But just because the combination of software is rare doesn't mean that we should disregard the possibility.
Now for a display of massive ignorance: I wonder what a PDF virus could do on a system whose GUI is based on PDF (Mac OS X)?
A good beginner's book on Java is Wrox's Beginning Java 2, by Ivor Horton. It has a couple of chapters that are not well put together (JDBC, I/O), but the book is really good at introducing you to the syntax, the mode of thought, etc, particularly for someone who does not have much programming experience.
Bruce Eckel's Thinking in Java is a great book for introducing C/C++ programmers to Java, and some of the coverage is excellent. However, some of what Eckel says is just plain wrong, particularly his coverage of Servlets. But that's okay, since you'll want subject/API-specific books by the time you get to those areas anyway.
Good servlet/JSP coverage is quickly had from the Wrox books: Professional JSP 2nd ed., Professional Java Server Programming J2EE ed., etc. Also, staples like Jason Hunter's Java Servlet Programming and Hans Bergsten's JavaServer Pages from O'Reilly are quite good, though less bang (ie, pages) for the buck.
Java in a Nutshell is an essential reference, but a really sucky introductory tutorial.
The best JDBC book I know of is the JDBC API Tutorial and Reference, 2nd ed. Avoid O'Reilly's JDBC book, it just isn't anywhere near as good, and the examples don't make much sense.
I've heard good things about Java IO and Java Networking by Elliott Rusty Harold from O'Reilly, but I've not had the chance to pick them up. Brett McLaughlin's Java and XML is good, but wait for the next edition.
If you are (or become) serious about Java (or any other OO language), you would do yourself a HUGE favor to pick up the Gang of Four's Design Patterns.
IIRC, the original author of DeCSS did not originally intend the code as a means of expression; instead, he whipped up DeCSS in order to watch movies. Of course, if I don't remember correctly, then my entire house of cards collapses...;)
DeCSS may have been co-opted as a symbol for the freedom fighters, but its original purpose was not to be such a symbol. I think my point is that DeCSS should not be so co-opted, and the decision should not come from a court of appeals. Instead, the freedom/intellectual property/copyright/patent issues should be decided upon by a court of constitutional law -- the Supreme Court. And the issue should be decided in the abstract, using examples from real life, rather than being decided by the merits of a single case.
I think the issue revolves (or perhaps should revolve) around the the intended purpose of the code in question, as expressed by its function and its design goals. As the first commenter in this series said, the purpose of e.g. the kernel is not to be beautiful. The purpose of the kernel is not to be art. The purpose of the kernel is to provide the user with a means of managing memory, etc.
That's not to say that code-as-art does not exist. PERL poetry, obfuscated C, and so forth all have a form of expression/art as part of their purpose -- the other part of their purpose is to perform whatever function(s) the program can do.
There are those who mention the beauty inherent in a mathematical proof, or the elegance of a well-designed and -coded program, and I freely agree with that statement. There is indeed much of beauty in some of the works of the mind. However, the intent of the mathematician or programmer was not (necessarily) to express beauty or some emotion through their work, the intent was to create a useful tool or advance science.
In effect, arguing that code == expression is over-simplifying. I would argue instead that code is really a medium that can be used for multiple purposes, including art, functionality, and algorithmic denotation.
This is a gray area. Architecture has multiple purposes: creating functional buildings, and creating beautiful/aesthetic buildings. The economic factors involved in architecture generally preclude making aesthetics the sole purpose of building -- making a pretty-but-non-functional-building doesn't usually recoup the cost of building.
"High art", however, is different. Its primary purpose is to express an affective meme -- instill an emotion in the viewer. Entertainment media are somewhere between the two -- their sole purpose is, again, expressing an affective meme, but some would argue that the meme they wish to express is not of as high a "value" as, say, a Rodin sculpture... though the cost of an episode of "Friends" would, I think, make an effective argument against that.;/
Code is IMO more like architecture, due to the economics. Code-as-art has little functional purpose -- but then, neither does a painting have functional purpose. And the cost of a high-functionality coding project is/can be quite high.
The gray area with code is that the cost of entry is not very high -- you just have to buy computer hardware, and put some time in to learn to code. But I think that it is evident that the original purpose of the DeCSS code was NOT to be art, but was to decrypt the CSS encryption on DVDs. In other words, not expression, but function.
On the other hand, DeCSS code in the shape of a dolphin on a ThinkGeek t-shirt...;)
But seriously, I'm not sure that the 2600/DeCSS case using the code==expression argument isn't a mistake. I don't think the DeCSS code was intended to be expressive in nature. However, we should be thinking very hard about the larger issue -- censorship of a particular medium. A medium that has multiple purposes, one of which is artistic expression. Television/movies have this in common with code -- some movies are documentaries whose purpose is to educate, while other movies' purpose is that of artistic expression. And as a result, freedom of expression within a movie/TV format is guaranteed (minus caveats regarding national security and public decency, and even public decency can be/is avoided by voluntary labeling).
And yet, Paul Graham's point is that it is possible to write really good code really quickly using LISP, and that LISP is easy to learn, if you can get your head around the paradigm/parentheses. As such, Graham says that what your coworkers know should not be relevant -- they should learn LISP if they don't know it already.
Notice the "should"s.
I have no personal experience with LISP. I just got finished reading some of the source code that Graham and Norvig have published on the Web. I didn't find it that hard to understand.
On the other hand, I am also rather new to programming, so maybe I don't suffer from a language rut yet.  But I doubt that.
Your objection that LISP doesn't have an extensive set of libraries is a more powerful stumbling block. That, after all, is one of the major things that makes Java so useful.
But I wonder if that objection is true? I'm not saying it isn't, because I simply don't know one way or the other. I do know that LISP libraries don't have anywhere near the exposure that the Java APIs have -- I haven't heard of any such libraries, for instance. But at the same time, I wonder whether such libraries exist and we are simply unaware of them?
And, of course, if you take Graham's argument to heart, we should all just sit down and write some, since LISP is (in his eyes) the best language.
The original commenter's point indeed: use the proper tool for the job. Graham would just reply the LISP is the best tool for the job.
The reason all that "dark" fiber is not being used is because, as the other replier mentioned, the cost to run extra, unneeded fiber is minimal. The cost to "light it up", however, is NOT inconsequential.
What this means to you and me is that there's a whole lot of capacity available for future expansion, as soon as someone or some organization/business/etc. is willing to pay for the bandwidth.
I've used Solaris 8 on x86. The general system performance is dreadful. Let this OS die a clean death.
We tested in our lab NFS performance of Solaris8 on x86, Solaris8 on SPARC, Linux 2.2 w/NFSv3 patches, Linux 2.4, and FreeBSD 4.x. Needless to say, when we compared apples to apples (discounting Solaris on SPARC), NFS performance ran, from slowest to fastest:
Solaris8 on x86, Linux 2.2, Linux 2.4, FreeBSD
We also tested disk IO and CPU/memory performance, and got the exact same line-up.
The tests were conducted on a PIII 650, 768MB RAM, 40GB ATA-66 HD, and Fast Ethernet.
For performance, we couldn't get better than FreeBSD. Of course, YMMV.
I hate to say it, but I haven't seen anything under *nix that will do CASE work.
I have experience with only two CASE tools, so my input will be limited, and both work strictly under M$ Windows. I've worked with Popkin's System Architect, and in my experience it is the most bug-ridden PITA program I've ever used, in any category.
I'm currently using Oracle Designer, and I've been highly impressed, with a few reservations.
Designer allows you to draw your ERD, then run a transformer to generate the physical design model. After you run the transformer, you can put in all your code, indexes, triggers, etc.
Then, you press a button, and your DDL scripts come out. Dead easy.
Theoretically, it'll also let you reverse engineer from a connection to a database. I say theoretically because I've not tried it.
Designer (obviously) will work REALLY WELL with Oracle. It'll allow you to generate Oracle-specific code (for versions 6 and up, IIRC) from, basically, soup-to-nuts of your back-end: table creation, constraints, indexes, triggers, and stored procedures -- in both PL/SQL and (theoretically, I haven't attempted it yet) Java.
Designer will also output SQL dialect for other varieties of databases: SQL Server, Sybase, Informix, DB2 are all included, IIRC. But most importantly for you, it will also export in ANSI92 SQL. So, PostgreSQL (I don't have any experience with mySQL) at least will be able to use the generated scripts with (hopefully) minimal by-hand modification.
I have some reservations regarding Designer, in that it seems to have several bugs. I say "seems", because it looks like there may be workarounds (or "the proper way to do things") that I simply haven't figured out yet. I've not found them to be deal-breakers as a tool choice yet, mostly because I can (and do) always go in and edit the resultant scripts by hand to tweak things here and there. However, my volume isn't high, and I don't have an unreasonable time commitment for completion. If you need your generated code to be 100% perfect all the time, well, Designer doesn't do that for me. YMMV.
Um, I think the main reason we don't have such a sophisticated UI is because we, as programmers, can't figure it out.
Let me clarify before you draw and quarter me.
At heart, you have a great idea: a computer interface that draws inferences about what you are doing, and what you are trying to do, and what you are likely to do, and configures itself on the fly based on those inferences.
Does this not, in itself, suggest the reason why we don't have such a UI?
In designing/architecting an application, analysts must first figure out what people do, what they need to do (not the same as the first), and how a computer system can be designed to assist.
A single-purpose application is pretty easy, e.g., serving web pages. It doesn't take much analysis to figure out how the process should work. A request comes in, and a response goes out. Simple. And yet, development (from scratch) takes a long time to get it right.
Now take an enterprise-level application with lots and lots of functions and features. The analysts spend an awful lot of time figuring out all of the use cases/data flows/work-flows/processes. They make their list, and check it twice (gratuitous holiday reference:).
In some cases, enterprise apps have taken YEARS to figure out. The coding is the (relatively) easy part, once the design is complete.
And now, you propose that we create a user interface that is smart enough to reconfigure itself dynamically in such a way as to cover every possible contingency that a general purpose operating system could possibly cover.
In all honesty, I like the idea. But I just don't see it as being possible. A computer is all about pre-defined situations: it can't handle unknown situations. The user interface subsystem (windowing environment) is designed to provide applications programmers with a standard set of widgets to use and a standard set of services that allow the apps programmers to concentrate on providing the functionality of the application without worrying about how to code up, say, the graphics engine that draws the windows. As such, it provides a common look-and-feel, a common framework within which the apps programmers can work.
What you are asking is that each application completely take over the user interface, and provide a completely customized environment that responds to events that are defined by the application. H'mm, gee, that kind of sounds like "full screen" mode to me. Or just doing away with a *windowed* multi-tasking environment, and all the advantages you get from being able to have multiple windows open on different apps.
The other important bit you seem to be missing is consistency. Yes, yes, "a foolish consistency is the hobgoblin of little minds", but note Emerson's inclusion of the word foolish. Implying that consistency may not be foolish.
Basically, if you have an operating system that responds contextually to every new process, you eliminate all consistency from the user interface. This may not be a bad thing, if the system is inherently perfect -- if it always responds properly to every request, and never, ever mistakes someone's intent. The system *HAS* to be perfect, because you've taken away any possibility of interaction with the system if it ever starts misinterpreting intent. Basically, you have to send the computer to therapy to correct its psychological dysfunction.
If you take away consistency, you are forced to have perfection, because consistency is the only way to be able to predict proper functioning and diagnose improper functioning. A desktop metaphor, with appropriate document, tool, and folder metaphors is very easy to understand in its basic functions, because it behaves (or should behave -- this is where UI designers fall down a lot) just like the physical world. Ideally, under the current scheme, your e-mail proggy should have an icon that looks like a mail box, and your word processor should look like a pen/typewriter/whatevah. For that matter, the icons for WordPerfect (the quill pen) and BlitzMail (a mail box) are lot more easily identifiable at quick glance than, say, M$ Office's collection of stylized capital letters.
I'm sorry, I don't know where I'm going with this, but I hope I've made a few points clearly enough that some of the issues are brought to light.
Consistency matters, particularly for those who use a computer as a tool rather than an occupation.
An operating system abstracts basic services. A windowing system abstracts graphical user interface elements, and provides a basic environment. Applications make use of these, and extend them in highly specific ways, to allow the user to get things done.
Ideally, the user interface SHOULD be completely inobtrusive, completely intuitive, completely responsive, and completely correct. As well as perfectly communicative. And people are working on individual areas of this, but I don't see us having the computing power on our desks to achieve these goals right now. And the analysts haven't figured out what everyone wants to do with computers yet, either, or how...;)
Thank you for your suggestions. Working on an Open Source project is something I've been wanting to do for a while now, but I have miniscule knowledge of C/C++. While I would like to add C/C++ to my roster of skills, it imposes a substantial bit of overhead to contributing.
I suspect I'll go peek at java.apache.org and jakarta.apache.org, and see if there is anything I can help with there, since Java is something I know.
And I completely agree with you, I've found my admin & tech support knowledge immensely useful in both the design stages and debugging stages of the projects I have done.
I agree, multiple skills in different areas increase your value immensely, and make you much more useful to a company.
That does not make you more hireable.
I myself have found it very hard to find a job in other areas -- to gain that experience in other areas. I have been a tech support-type for years now, with a BS in philosophy (part of my problem, no CS degree). I have made the transition to sysadmin, first in the Windows world, and now with various Unix flavors. What I'd *like* to do is move into programming. As it stands, I have a lot of valuable experience with computers, but little programming experience -- I use VBA and Access every day, but that doesn't count, and I realize this. I've taken courses in Oracle and Java, and I believe I have enough skills in these areas, combined with my skills in Unix/Apache administration, to be quite valuable.
But the recruiters I talk to don't seem to see this. Instead, I typically get a runaround speech that says they want to market me to my strengths (sysadmin), and away from my areas of inexperience, because that way I/they will make more money.
I'm not really willing to take a lower-paying job than I currently have -- in the area I live (NYC), my current salary is enough to be comfortable, but not enough to save much.
In addition, the starting salaries of the "junior" positions I seek are roughly equivalent to my current salary. The difference between myself and other candidates is that they (often) have more academic skills (BS in CS) than I, and are fresh out of school.
I have a lot to offer, but I keep running into a familiar refrain: no experience, no hireANDyou have too much experience elsewhere, work to your skills.
On the other hand, I convinced my current employer to hire a guy fresh out of school with extremely few skills and very limited experience, simply because I knew, on interviewing him, that he was intelligent enough to learn the job quickly enough to be useful. And, lo and behold, for the most part, he is useful.
The US political system was originally created with a couple of basic principles:
1) Power concentrated in the hands of one governmental body is a Bad Thing(TM).
2) The average citizen may not have the brains or the education to handle power responsibly. They may try to vote themselves Bread and Circuses out of nothing.
IMHO, 1) has proven true -- the spread of power between the three branches of government is a good thing, and has put a stop to some of the more ridiculous initiatives from any one of the branches. The tension between branches has contributed to maintaining the general political stance of the USA over the long term in a fairly middle-of-the-road position.
Again IMHO, 2) is very often true. The average American citizen is *still* not terribly well-educated -- though the state of education has improved enormously from the days when the main topic was "How To Plant Green Things and Make Them Grow" and little things like history, mathematics, philosophy, literature et al. were the province of the idle rich.
Basic education may be wide-spread and available to most (I understand this is a generalization, and may not apply to everyone; the state of education in the USA is not really my main point), but that does not mean that such education is adequate and sufficient to prevent people from misunderstanding all the ramifications of a given piece of legislature. Inasmuch as IANAL, the above goes for myself as well. Understanding comes with research, study, and thought, and too often neither I nor the vast majority make the time for this level of understanding -- I have other things to worry about, and that's why I (attempt to) elect decent, competent people to work on legislation for me.
My basic point is that while the ability to initiate a public referendum over the Internet sounds like a potentially wonderful thing, I believe that proper checks and balances need to be put in place to prevent the potential abuses of the application of digital signatures to legislation.
We shouldn't be able to bypass legislators and lawyers. They are there for a reason -- the system doesn't work as well without them. Yes, I am certainly aware of the abuses that arise from our current system, but that's because of a corruption of the logical model, if you will.
I think that we should be able to initiate a popular referendum using digital signatures, but there needs to be a system in place where the proposed legislature is reviewed extensively before it becomes law. This is a no-brainer point, but sometimes stating the obvious is not a bad thing...
The abovementioned link to "Quicktime for Linux" is nothing more than a reverse-engineered application wrapper that duplicates the functionality of Quicktime -- minus the Sorenson, and all other proprietary, non-Open Source codecs. Cool thought, but no banana...
Slashdot Mirror
... and then there are the managers out there who might read this book, assuming they knew it even existed. Managers who would be willing to accept help from others in improving their management skills. Concept, huh?
;-)
All generalizations are inaccurate -- including this one.
For a PDF from Apple on NetInfo, check out UnderstandingUsingNetInfo.pdf. I've looked it over, haven't read it yet, it seems to be a pretty decent intro.
Mike, the flip side of your last paragraph is somewhat more useful. I've used TogetherControlCenter to create class diagrams visually. The program generates (in my case, Java) code for each of those classes. Admittedly skeleton code, but it allows me to go from package/class design directly into fulfilling the contract laid down by the design. I've only used the "Community" version, so I have not had access to the other UML diagram types, but (according to the readme and help files) the other diagrams take the classes from the class diagram and add more code based on the other diagrams.
Bluntly, it is loads faster for me as an "all-in-one" analyst/designer/developer for me to do the design in such a UML diagrammer/code generation tool, then flesh out the rest of the code afterwards. For people who work in separate roles, if the analysts and designers are worth their paycheck as professional communicators, then they should be able to hand a coder a written specification that allows the coder to work just as quickly.
And, as to your original statement, Rational can indeed generate UML from code -- and then allow the user to manipulate the UML and thus generate new code.
At the base level, some people work well visually, and some don't. Those who work well visually and understand code and know their tools can use "proper" UML tools to make their lives much, much easier.
Idiot, read the article first. The new protocol takes care of latency, timing issues, packet collisions, etc. Did you honestly think that Gibson would be stupid enough to release something that doesn't address the fundamental flaws of Ethernet in regards to the problem domain?
Try a spreadsheet. Or build a simple database.
Seriously, if you have to type in the problem and the fix, it isn't going to kill you to type in an asset code or something. As a hint, if you're not using Dells (with their nifty little ID tags), and you want to avoid the pain of having to type in the full serial number each time, put together a table in your database where you have all the serial numbers of your items (type once), then link it to a short asset number. Get a label maker, put label on item. When item comes through your door, type in the asset number, and be done with it.
The pain and hassle of acquiring (relatively) expensive barcode readers and coding up the necessary software more than likely outweighs the pain and hassle of having to type in a serial number once and an asset number multiple times -- ESPECIALLY if you have to type anyway. The only time that barcoding is really worth it is if it can save you LARGE amounts of typing time. Normally, it can't. You will have to think long and hard about the ability of barcoding to automate work processes.
An example of the above is inventory: you can scan in the barcode of the item you are checking in, scan in the code of the shelf, scan in the bin/box/whatever, and your app will track where you put something. Great, right? Another real world example: a nurse scans the barcode of the patient's wristband, scans the barcode of the drug she has, and the app checks to see that the drug is indeed the one prescribed for this patient, and throws a warning if it isn't or if the dosage is incorrect. If it *is* the correct prescription and patient, the nurse dispenses the drug, then scans her *own* barcode, and the hospital information system records that the drug was dispensed by the nurse to the patient. The first application might be relatively easy to code; the second one is not.
The real question you should be asking yourself is whether you can automate your process so that you can achieve the same level of functionality without typing. When it comes to describing problems and resolutions, I don't think you can. Maybe you can create a list of barcodes for your common problems, and a list of codes for your normal resolutions, and automate that way -- but remember to make sure that the exceptions (when they inevitably happen) are not so hard to use that it's not more work than it is worth.
As another commenter pointed out, look at existing handhelds. It seems to me that what you want is a more-or-less fullsize keyboard and screen for something like the new Sharp Zaurus Linux PDA. So, instead of going nuts trying to build a laptop from scratch (neat idea, but WAY impractical IMHO), try finding or building or commissioning an expansion part: an adapter to whatever expansion slots exist on the Sharp or iPaq, which provides a USB controller and 2 ports (keyboard and mouse), and provides some sort of basic video out. As an alternative, a new cradle that has a built-in keyboard, trackpad, LCD screen and Ethernet port. Let the cradle have its own built-in battery (I hear fuel-cell technology is up-and-coming), and there you go. Add extra storage to taste (flash?), and you would really have something.
In fact, I'd buy something like that in a heart-beat. In all honesty, a gadget like this, truly well-designed and built, would make a good Linux-based hand-held into a truly killer device. Laptop manufacturers would be running scared!
I, too, have a BA in philosophy. My career in computers began quite a while ago (I'm 29 now), when I was in college. Like others who have posted, I got a job with the college's computer support group, where I learned basic troubleshooting for DOS, Windows 3.1, and Mac OS 6+. I enjoyed fixing things, so I pestered the hardware guy for a bit, and he took me under his wing and made me the junior repair person. By my last year there, I was managing the student workers. While I was there, I had no exposure to Unix at all; instead, we had a VAX/VMS that we students were never allowed to touch except as users, and all networking was DECnet and was also the domain of experts/full-time staff.
:). Anyway, my year up I went back to school and graduated.
I took a year off from school, and parlayed my experience into full-time jobs doing tech support -- one on a contract, the other at a company that went Chapter 11 and got dissolved (anybody remember Dove modems for Macs?
After graduation, I got another contract job, working for (dons flame-retardant long-johns) Microsoft, doing telephone tech support for Word and Windows 95. They gave us some pretty amazing training before letting us loose on the phones... then some bean-counter came on board as a VP, and decided to make his mark on the bottom line by eliminating as many contractors as possible.
After that, I went through a series of short-term contract jobs, then got a permanent job as tech support/project manager/computer trainer for a (very) small hospital. That was my first exposure to NT administration. I had another brief stint at contracting after 18 months at the hospital, and am now working (for the past three years) at a much larger hospital as the "network administrator" for a particular department.
I've been here for 2.5 years now, and have not done much network admin in Windows; our centralized IS department keeps the servers. I've done tons of tech support, and worked my way through a certificate program in Java & Oracle development, taught myself VBA and built some Access databases, and got myself promoted. Now I do database programming (currently working on a home-grown lab management system using PostgreSQL and Tomcat), and have been introduced to Unix in a neat way -- we are a research department, and we hired a statistical geneticist. He brought with him a couple of Sun Ultra 10's, and the department shipped me off for Solaris training in order to support him. We expanded the number of machines, and have been installing FreeBSD on our standard Compaq desktops, and running Linux on one Alpha machine and Tru64 on the other.
The statistician introduced me to O'Reilly, and I've been reading like crazy and practicing on the side, constantly learning (Python at the moment).
So now I have a very wide range of skills, and a fair bit of depth in a couple of different areas. I'm not a full-time Unix sysadmin, but I probably would qualify for a jr. level sysadmin job somewhere. I'm not a full-time Java programmer, but would probably do pretty well in a junior-to-mid level position.
Hehe, anybody hiring...?
We faced a similar problem, and the answer is ugly, but simple: Oracle doesn't work on Linux for Alpha.
We originally bought an Atipa Linux Alpha machine running Tru64, with the intent of running Oracle on it. We specced it out with an internal RAID controller and three U160 SCSI 10k (or is it 15, I forget...) drives. When we got the machine, we found out that Atipa had substituted a different RAID card, because the one originally specified (128 MB cache, 3 channels, whiz-bang...) wasn't supported under Tru64. In fact, on our system, the only card supported is a measly 4MB cache, single-channel card. We were seeing approx 6MB/second throughput using RAID 5.
Needless to say, we were not happy.
Long story short, after much runaround, they sold us the card we had specced *AT 1/3 THE PRICE OF THE COMPAQ CARD*, and we installed Linux instead. We now get ~45MB/second sustained throughput under RAID 5. Then we found that Oracle doesn't work/hasn't been tested on Linux for Alpha. In the end, we are using PostgreSQL, and are quite happy with it. But, our database is relatively small and has few connections -- it's used to mirror the BLAST databases for internal research.
My understanding (pass along as rumor, but from the CNET article, MacSlash, etc., so it may have *some* slight credibility) is that the retailers (Apple Stores, CompUSA, whatever) will hand out CDs both of the update itself and the updated developer tools CD.
The devtools CD is also supposed to be in the retail 10.1 box.
Okay, agreed that Jakarta is cool -- BUT. You missed the point in a big way, and you have a glaring error of fact in your comment.
Tomcat is excellent, but there is no such thing as a J2EE servlet engine, and you characterizing it as such is doing both Tomcat and Ganesh's article a disservice. The fact is that a servlet/JSP engine is a cool deal, but by itself it is not J2EE, and doesn't bring with it all the benefits that J2EE brings. Yes, servlets/JSPs are cool, but they are, at heart, part of the presentation layer of an n-tier architecture. If the world needs an enterprise-class solution, with clustering, redundancy, scalability, five 9s, they can't do it with Tomcat, at least by itself. Servlets are cool, yes, but Tomcat as a servlet engine doesn't have what it takes to handle enterprise-level requirements of stability, clustering, etc.
The point that Ganesh was attempting to make was that the OSS community at large needs to wake up from our communal head-in-the-sand attitude about Java and J2EE, and realize that aside from Java there really aren't a whole lot of options for enterprise-level stuff.
(Zope provides one option, but the documentation was horrendous last I looked, and Zope was not easy to configure as an experiment. The "roll yer own, it's all open standards" folks also have a valid point, but businesses seek productivity *gains* by reusing existing, known-good frameworks rather than being forced into productivity *losses* because you have to write your own framework first.)
Web services is really only the communication layer, and really only the automated communication layer -- but that's a very important layer. Yet still, the underlying business-class functionality (in other words, the services a business has to offer the world), is what's important, and Microsoft has done a pretty darn good job with marketspeak and packaging, and has begun selling an end-to-end solution, a solution that promises M$ domination on the back-end to the same degree as on the desktop.
And that is Ganesh's point: we need to either write our own enterprise-level component-based web services soup-to-nuts framework, or we need to unite behind an existing framework (Java, J2EE), or we will wind up suffocating in M$ products all the way around.
Tomcat itself is irrelevant, except as a (vital) component of the existing alternative architecture. And you'll notice that, of the major servlet engine vendors, pretty much all of them now sell J2EE containers that incorporate their prior servlet engine -- Weblogic, Websphere, JRUN... And one notable database vendor (another major part of the enterprise computing framework) has decided to enter the same marketspace with their own offering: Oracle's 9iAS.
As many have already noted, the embedded VBScript will only run when triggered by someone double-clicking on the file annotation included in the PDF while using the full version of Acrobat. Thus, the virus is not particularly dangerous.
The social engineering, however, is pretty amazing. The author has created a neat little PDF "game" that people will want to double-click. And, as he wrote in the text file linked above, he wrote it as a proof of concept. The worm doesn't do much except spread itself using Outlook. I think the scary part, the point the author wanted to make, is that you can embed all sorts of fun things in a PDF file. Some other virus writer could make a new version that does something nasty after it emails itself to every address it can find in your Outlook folders.
Yes, the threat level is low, due to the required combination of software and social engineering. But just because the combination of software is rare doesn't mean that we should disregard the possibility.
Now for a display of massive ignorance: I wonder what a PDF virus could do on a system whose GUI is based on PDF (Mac OS X)?
A good beginner's book on Java is Wrox's Beginning Java 2, by Ivor Horton. It has a couple of chapters that are not well put together (JDBC, I/O), but the book is really good at introducing you to the syntax, the mode of thought, etc, particularly for someone who does not have much programming experience.
Bruce Eckel's Thinking in Java is a great book for introducing C/C++ programmers to Java, and some of the coverage is excellent. However, some of what Eckel says is just plain wrong, particularly his coverage of Servlets. But that's okay, since you'll want subject/API-specific books by the time you get to those areas anyway.
Good servlet/JSP coverage is quickly had from the Wrox books: Professional JSP 2nd ed., Professional Java Server Programming J2EE ed., etc. Also, staples like Jason Hunter's Java Servlet Programming and Hans Bergsten's JavaServer Pages from O'Reilly are quite good, though less bang (ie, pages) for the buck.
Java in a Nutshell is an essential reference, but a really sucky introductory tutorial.
The best JDBC book I know of is the JDBC API Tutorial and Reference, 2nd ed. Avoid O'Reilly's JDBC book, it just isn't anywhere near as good, and the examples don't make much sense.
I've heard good things about Java IO and Java Networking by Elliott Rusty Harold from O'Reilly, but I've not had the chance to pick them up. Brett McLaughlin's Java and XML is good, but wait for the next edition.
If you are (or become) serious about Java (or any other OO language), you would do yourself a HUGE favor to pick up the Gang of Four's Design Patterns.
---Good luck!
FYI, Oracle has created its own Linux distro. Unfortunately for us ugly Americans, it is only produced by their Japanese subsidiary, IIRC.
Has anybody else noticed how Japan seems to get all the cool toys first? Transmeta notebooks come to mind as an example...
Okay, let me break it down:
;)
art == expression
No arguments there, I hope.
Now for my points:
!(code != expression)
Code CAN be expression -- but doesn't have to be.
!(expression == art)
Not all expression is art. Some is, but not all.
DeCSS == DVD decryptor
DeCSS was designed to be a DVD decryptor.
DVD decryptor != expression
IIRC, the original author of DeCSS did not originally intend the code as a means of expression; instead, he whipped up DeCSS in order to watch movies. Of course, if I don't remember correctly, then my entire house of cards collapses...
DeCSS may have been co-opted as a symbol for the freedom fighters, but its original purpose was not to be such a symbol. I think my point is that DeCSS should not be so co-opted, and the decision should not come from a court of appeals. Instead, the freedom/intellectual property/copyright/patent issues should be decided upon by a court of constitutional law -- the Supreme Court. And the issue should be decided in the abstract, using examples from real life, rather than being decided by the merits of a single case.
I think the issue revolves (or perhaps should revolve) around the the intended purpose of the code in question, as expressed by its function and its design goals. As the first commenter in this series said, the purpose of e.g. the kernel is not to be beautiful. The purpose of the kernel is not to be art. The purpose of the kernel is to provide the user with a means of managing memory, etc.
;/
;)
That's not to say that code-as-art does not exist. PERL poetry, obfuscated C, and so forth all have a form of expression/art as part of their purpose -- the other part of their purpose is to perform whatever function(s) the program can do.
There are those who mention the beauty inherent in a mathematical proof, or the elegance of a well-designed and -coded program, and I freely agree with that statement. There is indeed much of beauty in some of the works of the mind. However, the intent of the mathematician or programmer was not (necessarily) to express beauty or some emotion through their work, the intent was to create a useful tool or advance science.
In effect, arguing that code == expression is over-simplifying. I would argue instead that code is really a medium that can be used for multiple purposes, including art, functionality, and algorithmic denotation.
This is a gray area. Architecture has multiple purposes: creating functional buildings, and creating beautiful/aesthetic buildings. The economic factors involved in architecture generally preclude making aesthetics the sole purpose of building -- making a pretty-but-non-functional-building doesn't usually recoup the cost of building.
"High art", however, is different. Its primary purpose is to express an affective meme -- instill an emotion in the viewer. Entertainment media are somewhere between the two -- their sole purpose is, again, expressing an affective meme, but some would argue that the meme they wish to express is not of as high a "value" as, say, a Rodin sculpture... though the cost of an episode of "Friends" would, I think, make an effective argument against that.
Code is IMO more like architecture, due to the economics. Code-as-art has little functional purpose -- but then, neither does a painting have functional purpose. And the cost of a high-functionality coding project is/can be quite high.
The gray area with code is that the cost of entry is not very high -- you just have to buy computer hardware, and put some time in to learn to code. But I think that it is evident that the original purpose of the DeCSS code was NOT to be art, but was to decrypt the CSS encryption on DVDs. In other words, not expression, but function.
On the other hand, DeCSS code in the shape of a dolphin on a ThinkGeek t-shirt...
But seriously, I'm not sure that the 2600/DeCSS case using the code==expression argument isn't a mistake. I don't think the DeCSS code was intended to be expressive in nature. However, we should be thinking very hard about the larger issue -- censorship of a particular medium. A medium that has multiple purposes, one of which is artistic expression. Television/movies have this in common with code -- some movies are documentaries whose purpose is to educate, while other movies' purpose is that of artistic expression. And as a result, freedom of expression within a movie/TV format is guaranteed (minus caveats regarding national security and public decency, and even public decency can be/is avoided by voluntary labeling).
What do you think?
And yet, Paul Graham's point is that it is possible to write really good code really quickly using LISP, and that LISP is easy to learn, if you can get your head around the paradigm/parentheses. As such, Graham says that what your coworkers know should not be relevant -- they should learn LISP if they don't know it already.
;)
Notice the "should"s.
I have no personal experience with LISP. I just got finished reading some of the source code that Graham and Norvig have published on the Web. I didn't find it that hard to understand. On the other hand, I am also rather new to programming, so maybe I don't suffer from a language rut yet.  But I doubt that.
Your objection that LISP doesn't have an extensive set of libraries is a more powerful stumbling block. That, after all, is one of the major things that makes Java so useful. But I wonder if that objection is true? I'm not saying it isn't, because I simply don't know one way or the other. I do know that LISP libraries don't have anywhere near the exposure that the Java APIs have -- I haven't heard of any such libraries, for instance. But at the same time, I wonder whether such libraries exist and we are simply unaware of them?
And, of course, if you take Graham's argument to heart, we should all just sit down and write some, since LISP is (in his eyes) the best language.
The original commenter's point indeed: use the proper tool for the job. Graham would just reply the LISP is the best tool for the job.
Have I been smarmy enough yet...?
The reason all that "dark" fiber is not being used is because, as the other replier mentioned, the cost to run extra, unneeded fiber is minimal. The cost to "light it up", however, is NOT inconsequential.
What this means to you and me is that there's a whole lot of capacity available for future expansion, as soon as someone or some organization/business/etc. is willing to pay for the bandwidth.
Supply and demand. Easy-peasy.
Um, for what little it's worth (about .00002 last I checked... :) "usr" actually stands for Unix System Resources.
I've used Solaris 8 on x86. The general system performance is dreadful. Let this OS die a clean death.
We tested in our lab NFS performance of Solaris8 on x86, Solaris8 on SPARC, Linux 2.2 w/NFSv3 patches, Linux 2.4, and FreeBSD 4.x. Needless to say, when we compared apples to apples (discounting Solaris on SPARC), NFS performance ran, from slowest to fastest:
Solaris8 on x86, Linux 2.2, Linux 2.4, FreeBSD
We also tested disk IO and CPU/memory performance, and got the exact same line-up.
The tests were conducted on a PIII 650, 768MB RAM, 40GB ATA-66 HD, and Fast Ethernet.
For performance, we couldn't get better than FreeBSD. Of course, YMMV.
I hate to say it, but I haven't seen anything under *nix that will do CASE work.
I have experience with only two CASE tools, so my input will be limited, and both work strictly under M$ Windows. I've worked with Popkin's System Architect, and in my experience it is the most bug-ridden PITA program I've ever used, in any category.
I'm currently using Oracle Designer, and I've been highly impressed, with a few reservations. Designer allows you to draw your ERD, then run a transformer to generate the physical design model. After you run the transformer, you can put in all your code, indexes, triggers, etc.
Then, you press a button, and your DDL scripts come out. Dead easy.
Theoretically, it'll also let you reverse engineer from a connection to a database. I say theoretically because I've not tried it.
Designer (obviously) will work REALLY WELL with Oracle. It'll allow you to generate Oracle-specific code (for versions 6 and up, IIRC) from, basically, soup-to-nuts of your back-end: table creation, constraints, indexes, triggers, and stored procedures -- in both PL/SQL and (theoretically, I haven't attempted it yet) Java.
Designer will also output SQL dialect for other varieties of databases: SQL Server, Sybase, Informix, DB2 are all included, IIRC. But most importantly for you, it will also export in ANSI92 SQL. So, PostgreSQL (I don't have any experience with mySQL) at least will be able to use the generated scripts with (hopefully) minimal by-hand modification.
I have some reservations regarding Designer, in that it seems to have several bugs. I say "seems", because it looks like there may be workarounds (or "the proper way to do things") that I simply haven't figured out yet. I've not found them to be deal-breakers as a tool choice yet, mostly because I can (and do) always go in and edit the resultant scripts by hand to tweak things here and there. However, my volume isn't high, and I don't have an unreasonable time commitment for completion. If you need your generated code to be 100% perfect all the time, well, Designer doesn't do that for me. YMMV.
Good luck!
Let me clarify before you draw and quarter me.
At heart, you have a great idea: a computer interface that draws inferences about what you are doing, and what you are trying to do, and what you are likely to do, and configures itself on the fly based on those inferences.
Does this not, in itself, suggest the reason why we don't have such a UI?
In designing/architecting an application, analysts must first figure out what people do, what they need to do (not the same as the first), and how a computer system can be designed to assist.
A single-purpose application is pretty easy, e.g., serving web pages. It doesn't take much analysis to figure out how the process should work. A request comes in, and a response goes out. Simple. And yet, development (from scratch) takes a long time to get it right.
Now take an enterprise-level application with lots and lots of functions and features. The analysts spend an awful lot of time figuring out all of the use cases/data flows/work-flows/processes. They make their list, and check it twice (gratuitous holiday reference
In some cases, enterprise apps have taken YEARS to figure out. The coding is the (relatively) easy part, once the design is complete.
And now, you propose that we create a user interface that is smart enough to reconfigure itself dynamically in such a way as to cover every possible contingency that a general purpose operating system could possibly cover.
In all honesty, I like the idea. But I just don't see it as being possible. A computer is all about pre-defined situations: it can't handle unknown situations. The user interface subsystem (windowing environment) is designed to provide applications programmers with a standard set of widgets to use and a standard set of services that allow the apps programmers to concentrate on providing the functionality of the application without worrying about how to code up, say, the graphics engine that draws the windows. As such, it provides a common look-and-feel, a common framework within which the apps programmers can work.
What you are asking is that each application completely take over the user interface, and provide a completely customized environment that responds to events that are defined by the application. H'mm, gee, that kind of sounds like "full screen" mode to me. Or just doing away with a *windowed* multi-tasking environment, and all the advantages you get from being able to have multiple windows open on different apps.
The other important bit you seem to be missing is consistency. Yes, yes, "a foolish consistency is the hobgoblin of little minds", but note Emerson's inclusion of the word foolish. Implying that consistency may not be foolish.
Basically, if you have an operating system that responds contextually to every new process, you eliminate all consistency from the user interface. This may not be a bad thing, if the system is inherently perfect -- if it always responds properly to every request, and never, ever mistakes someone's intent. The system *HAS* to be perfect, because you've taken away any possibility of interaction with the system if it ever starts misinterpreting intent. Basically, you have to send the computer to therapy to correct its psychological dysfunction.
If you take away consistency, you are forced to have perfection, because consistency is the only way to be able to predict proper functioning and diagnose improper functioning. A desktop metaphor, with appropriate document, tool, and folder metaphors is very easy to understand in its basic functions, because it behaves (or should behave -- this is where UI designers fall down a lot) just like the physical world. Ideally, under the current scheme, your e-mail proggy should have an icon that looks like a mail box, and your word processor should look like a pen/typewriter/whatevah. For that matter, the icons for WordPerfect (the quill pen) and BlitzMail (a mail box) are lot more easily identifiable at quick glance than, say, M$ Office's collection of stylized capital letters.
I'm sorry, I don't know where I'm going with this, but I hope I've made a few points clearly enough that some of the issues are brought to light.
Ideally, the user interface SHOULD be completely inobtrusive, completely intuitive, completely responsive, and completely correct. As well as perfectly communicative. And people are working on individual areas of this, but I don't see us having the computing power on our desks to achieve these goals right now. And the analysts haven't figured out what everyone wants to do with computers yet, either, or how...
Thank you for your suggestions. Working on an Open Source project is something I've been wanting to do for a while now, but I have miniscule knowledge of C/C++. While I would like to add C/C++ to my roster of skills, it imposes a substantial bit of overhead to contributing.
I suspect I'll go peek at java.apache.org and jakarta.apache.org, and see if there is anything I can help with there, since Java is something I know.
And I completely agree with you, I've found my admin & tech support knowledge immensely useful in both the design stages and debugging stages of the projects I have done.
Thanks again!
I agree, multiple skills in different areas increase your value immensely, and make you much more useful to a company.
That does not make you more hireable.
I myself have found it very hard to find a job in other areas -- to gain that experience in other areas. I have been a tech support-type for years now, with a BS in philosophy (part of my problem, no CS degree). I have made the transition to sysadmin, first in the Windows world, and now with various Unix flavors. What I'd *like* to do is move into programming. As it stands, I have a lot of valuable experience with computers, but little programming experience -- I use VBA and Access every day, but that doesn't count, and I realize this. I've taken courses in Oracle and Java, and I believe I have enough skills in these areas, combined with my skills in Unix/Apache administration, to be quite valuable.
But the recruiters I talk to don't seem to see this. Instead, I typically get a runaround speech that says they want to market me to my strengths (sysadmin), and away from my areas of inexperience, because that way I/they will make more money.
I'm not really willing to take a lower-paying job than I currently have -- in the area I live (NYC), my current salary is enough to be comfortable, but not enough to save much.
In addition, the starting salaries of the "junior" positions I seek are roughly equivalent to my current salary. The difference between myself and other candidates is that they (often) have more academic skills (BS in CS) than I, and are fresh out of school.
I have a lot to offer, but I keep running into a familiar refrain: no experience, no hire AND you have too much experience elsewhere, work to your skills.
On the other hand, I convinced my current employer to hire a guy fresh out of school with extremely few skills and very limited experience, simply because I knew, on interviewing him, that he was intelligent enough to learn the job quickly enough to be useful. And, lo and behold, for the most part, he is useful.
Go figger...
---Phoukka
The US political system was originally created with a couple of basic principles:
1) Power concentrated in the hands of one governmental body is a Bad Thing(TM).
2) The average citizen may not have the brains or the education to handle power responsibly. They may try to vote themselves Bread and Circuses out of nothing.
IMHO, 1) has proven true -- the spread of power between the three branches of government is a good thing, and has put a stop to some of the more ridiculous initiatives from any one of the branches. The tension between branches has contributed to maintaining the general political stance of the USA over the long term in a fairly middle-of-the-road position.
Again IMHO, 2) is very often true. The average American citizen is *still* not terribly well-educated -- though the state of education has improved enormously from the days when the main topic was "How To Plant Green Things and Make Them Grow" and little things like history, mathematics, philosophy, literature et al. were the province of the idle rich.
Basic education may be wide-spread and available to most (I understand this is a generalization, and may not apply to everyone; the state of education in the USA is not really my main point), but that does not mean that such education is adequate and sufficient to prevent people from misunderstanding all the ramifications of a given piece of legislature. Inasmuch as IANAL, the above goes for myself as well. Understanding comes with research, study, and thought, and too often neither I nor the vast majority make the time for this level of understanding -- I have other things to worry about, and that's why I (attempt to) elect decent, competent people to work on legislation for me.
My basic point is that while the ability to initiate a public referendum over the Internet sounds like a potentially wonderful thing, I believe that proper checks and balances need to be put in place to prevent the potential abuses of the application of digital signatures to legislation.
We shouldn't be able to bypass legislators and lawyers. They are there for a reason -- the system doesn't work as well without them. Yes, I am certainly aware of the abuses that arise from our current system, but that's because of a corruption of the logical model, if you will.
I think that we should be able to initiate a popular referendum using digital signatures, but there needs to be a system in place where the proposed legislature is reviewed extensively before it becomes law. This is a no-brainer point, but sometimes stating the obvious is not a bad thing...
---Phoukka
The abovementioned link to "Quicktime for Linux" is nothing more than a reverse-engineered application wrapper that duplicates the functionality of Quicktime -- minus the Sorenson, and all other proprietary, non-Open Source codecs. Cool thought, but no banana...