Lean IT is about delivering quickly and cheaply, Agile about delivering high value compared to the costs, devops about taking responsibility for your work. If you start with one of these methods and take it to its logical conclusions, you'll end up with something that isn't very far from the others.
The idea that you can start with a mishmash of all three is probably not productive - there's a kind of learning journey you have to go through - but I'm willing to change my mind if somebody delivers proof.
You don't want to make it even more cumbersome to change the code, as it sounds like you are already struggling with the 10 Mloc codebase. So forget about having humans "approve" the changes.
What you want to do is make it easy to submit good code and difficult to submit bad code. This means that you will need the capability to quickly assess the proposed patch, for some definition of "good" and "bad". Computers are fairly good at this. In other words: test-first development, with automated testing on several levels.
Bug comes in, you write an automated user acceptance test that FAILS. Then you try to find and fix the bug. When the newly added test passes, the bug is by definition fixed. Add a couple of unit/module tests, and a couple of UATs for good measure. Rinse and repeat.
There's plenty of tools for this. All major platforms have the capability for programmatic reflection. Use e.g. Cucumber for the acceptance tests, and the relevant unit test framework for module/unit tests. In addition to the functional tests, try static analysis.
Is this an article about how the Windows 8 UI was designed?
Or about how they kept the world's population hostage with Clippy the Paperclip? I mean, when they heard Clippy was going to be removed from the next version of Office, around 350 million people upgraded straight away.
Or is it about how Microsoft is paying 500 million (USD, EUR, whatever) in fines every couple of years, in order to keep doing business as a software monopoly? That is probably the most brilliant crime by the Microsoft Digital Crimes Unit ever!
Learn to juggle! Seriously! I learned to juggle with three balls during a particularly stressful software project some 15 years ago. Nowadays when I feel blocked, I pick up three round objects and go somewhere else to juggle for a while. I haven't progressed beyond three objects but then again I'm not doing it for the fame and the money.:)
Juggling activates other parts of your brain than you (as a software engineer or IT guy) normally use. You can juggle as long as you like, ten seconds or ten minutes. The materials (e.g. stress balls, tennis balls, apples, oranges, whatever) are cheap and small. Does you good to get up out of that chair and stop staring at the monitor for a moment. If someone asks what you are doing, say that you're taking a minute to think about some small creative problem e.g. structuring the next three paragraphs you are writing, or looking for alternative ways to implement some feature. The learning threshold is admittedly steep, but the Internet should be full of tutorial videos by now. Also, juggling is a nice party trick, kids especially are fascinated.
> It's a fact that OS/UI developers seem to believe that [something]
A seeming fact, then? Or an opinion?
> we generally need increasingly large displays [read: pixel counts] in order to restore focus on the application and to minimize the impact on screen and usability which the OS/UI claims.
Not at all. We generally need more and better modes of interacting with our phones and the apps running on them. You see, there is an upper limit to the physical size of a phone: it needs to fit into your pocket. And there is also a lower limit on the size of an UI element: your fingertip. Increasing the resolution only enables the device to show sharper text and more detailed pictures.
There are many "novel" or "trendy" interaction methods like swiping, pinching, multi-finger dragging, gestures and so on, that are not yet commonly used in mobile phones or mobile apps. Properly used, they can free up screen estate. For example, an app that supports pinching doesn't need on-screen zoom buttons.
Many if not all of these interaction methods can profitably be reserved for the system UI. If you replace the most common system UI functions with gestures, you can remove the status and system bars and free up the top and bottom part of the screen. The Android 2.x swipe-from-the-top action is a good example, as it allows the top status bar to become very narrow. However there is no reason to stop there.
> Android 2.x seeks to minimize the UI impact and it does a nice job of it. A minimal row of buttons
No it doesn't. The iPhone minimizes the UI impact by simply NOT having that row of buttons. The Nokia N9 uses swiping creatively to do away with even the physical buttons and touch areas that you find on Androids, iPhones and Windows Phones.
All of these phones, even the N9, still have a slim status area at the top. Jolla's Sailfish aims to do away with even that.
> What Ubuntu-phone is proposing is unintuitive and seeks to infringe on how an app can live on a device. Do. Not. Want.
So you say. Now, in the real world, what Unbuntu proposes is really going to make some if not all of the system areas redundant and give apps more control over the screen real estate.
What is intuitive, by the way? In this context something is intuitive if you can pick it up and use it without training. It's not even remotely synonymous with "whatever I've gotten used to", as you seem to imply.
Have you actually tried a swipe UI? I have been using a swipe-based phone (the aforementioned N9) for a long time now, and it just works. You can either take my word for it, or go and try it yourself before commenting further.
"Remember that all models are wrong; the practical question is how wrong do they have to be to not be useful." (George E.P. Box and Norman R. Draper, Empirical Model-Building and Response Surfaces (1987), p. 74)
"One of the most insidious and nefarious properties of scientific models is their tendency to take over, and sometimes supplant, reality." (Erwin Chargaff)
One wonders if they'll be turned off by Celine Dion music — a new type of shark repellent perhaps?
Oh yes, the "Celine Dion effect" is well known. For example, playing My Heart Will Go On in railway stations late at night will magically keep the stations empty from pickpockets, rapists and other miscreants and indeed any sentient beings except cockroaches. The high notes will first melt your earwax and then your brain. Cockroaches merely lose their orientation and walk into walls.
I don't see any reason why it wouldn't work underwater too. Unless of course the sharks fight back with lasers.
One element I pushed was that nobody was going to be interested in their kernel, regardless of what they did, and that conversion to Linux would eventually be necessary if they were not to continue to expend millions on re-inventing the wheel.
Not a good thing to push because the kernel is the interesting part of Symbian. It's power-tight and has real-time features, both of which are very nice features in a mobile communications device. Unfortunately it only runs on ARM. Linux on the other hand runs on everything. With Qt on top of both Symbian and MeeGo, there's nowhere Nokia can't go. (There's no guarantee they'll actually go there, but they *could*.)
Ouch - this is the best that Hubble can do? The images show serious chromatic aberrations, with significant red-blue fringing on edges. What's worse is that the effect gets more pronounced as the camera moves around.
Given that the camera moves at relativistic speeds, the chromic aberrations are probably a relativistic effect and would of course get more pronounced the faster the camera moves. Another interesting side effect is that while for you the movie is over in a matter of minutes, someone observing you will feel that the movie takes too long, and incidentally also perceive you as significantly smaller.
I said nothing about the font handling process or font data formats. I said that the *results* are good. Sheesh.
If the Computer Modern font does not please your eyes, you can get any of the 35 standard PostScript fonts with one puny usepackage statement (e.g. \usepackage{times}). The procedure for installing arbitrary TrueType or PostScript fonts is a bit more involved but there are tools and walkthroughs available. See also http://www.tug.org/fonts/.
There are TeX forks like XeTeX that can handle modern digital fonts automatically.
Except that in this case, you can bring out a magnifying glass and see the differences yourself. Kerning and layout is an art that has been perfected for centuries. For example, the visual weights of the letters must be accounted for. You can't just put letters on a line one after another and expect the results to be nice or even readable. TeX/LaTeX was designed to reproduce the implicit and explicit rules of text layout and kerning. It has a separate font rendering library called Metafont. The results are very good, so good in fact that many have been content to write front-ends that call TeX or LaTeX for typesetting.
MS Word was designed by engineers to dump letters in sequence on paper. Early versions were unable to kern at less than screen resolution (some 75dpi). Later versions shipped with TrueType fonts lacking proper kerning information. The results are not good. So bad, in fact, that people turn to other alternatives. Reading documents "typeset" by Word in Times New Roman hurts your eyes, just like listening to 96 kbps MP3:s hurts your ears.
The notion that the writer is agnostic of the typesetting procedure and methods with LaTeX is a complete lie. I've never had to worry about ratios, measurements, indentations, word-per-line, empty pages and other problems as I have in LaTex.
This doesn't reflect my experience at all. The general settings are tuned once and for all in the preamble, you just focus on the writing and enjoy the results. You don't need to know anything about the typesetting procedures and methods.
For example, my 93-page thesis was typeset as \documentclass[a4paper, 12pt, titlepage, oneside, parskip]{scrreprt}. All settings are global, located in the preamble or at the very start of the body. Aside from some words that had to be explicitly hyphenated, there is absolutely no "tuning" of any kind in the main text to avoid orphans, widows, weird word-per-line counts, etc. There are no orphans, widows or weird word-per-line counts. The document looks good, just like the dozens if not hundreds of LaTeX documents I've written previously. (Looks only, mind you, I'm not vouchsafing for the contents.:))
If LaTeX inserts empty pages for you, you are probably using a document format which allows page padding before chapters. If LaTeX allows weird word-per-line counts, probably the page or column is so narrow that it's impossible to do a good job (without tuning the penalty variables). And so on.
Above all, LaTeX is totally deterministic. You make a change and it stays changed. And it works nicely with various version control systems, so you can do major edits without fear of losing your work, visual diffs, merges, etc.
There's an OSS Matlab clone called GNU Octave, see http://www.octave.org/. It's mostly compatible with Matlab. I've been using it for handling larger datasets or maths-heavy stuff. Works fine.
--Bud
Every team or group in the company is made responsible for (a) writing down their own values and processes on a Wiki page and (b) listing their obligations to other teams. The former is called the "team charter" and the latter a "service level agreement". Tell them that they will be required to sign these charters and agreements later. They are of course allowed to cooperate with other team, e.g. the testers might need to create a common template, or talk to the software development team about their obligations. Make clear what you expect to see, then ask them to come to you to get it accepted when they're done.
Length, detail and quality doesn't really matter. One page of text will do a long as it covers most things. E.g. "We are software professionals and like other people's code to be well designed, well written, well documented and not too optimized. In return we will write our own code to that spec. [...] We believe that domain knowledge is improved by creating throw-away prototypes and mockups. [...] For defects we use Bugzilla; the guy who currently owns the Bug Fixing Hat is responsible for performing triage daily on the new bugs. For version control we use Subversion; the guy who has the Builder hat is responsible for creating fresh weekly builds..." etc etc.
Measure the number of teams that have posted their team charters and service level agreements in the Wiki. Give a small goodie (toy, bonus) to the teams when they complete the charters and SLAs. Post the number of teams and the percentage of all teams in the company's internal newsletter. When there are only a few teams left, post the names of these teams in the "hall of shame".
Pick a handful of random teams. Visit them and make them explain what they have written and the rationale behind it. Have they listed all team that depend on them? Are they doing stuff that's not in the charter? Does the charter contain outdated practices? If they say they're happy with the charter, print it and make them sign it. If they don't want to sign it because they're not done yet, make them update it until they are happy with it.
[...] first have to go to a retail store [...] they will be able to download one of just 37 albums available through the service, including Britney Spears' "Blackout" and Barry Manilow's "The Greatest Songs of the Seventies."'"
Uhh... great artist selection, there. If I have to walk down to the retail store and then choose between Britney and Barry Manilow, I would rather save my hard-earned money.
Within a couple of months Sony will "accidentally" leak the sad numbers of their non-DRM trial to select members of the press, who will then write scathing opinion pieces about how the rampant piracy is so widespread that even removing DRM can't help the music industry.
Assuming that you enjoy your current job and are willing to fight this, you should try social engineering. Apparently some people in the company are trying to bully you into signing over your copyrights. The way to handle this is to bring it out into the open and make the bully the laughing stock.
Discuss the agreement with your colleagues over coffee and/or lunch. Collect a bunch of alpha geeks and other thought leaders among your co-workers. As the representatives for a group of outraged employees (i.e. yourselves, unless the whole department is outraged), brainstorm some tricky questions and schedule a meeting with the guy who tries to enforce the agreement. Then walk in to his room, sit down and start asking tricky/stupid/self-evident questions. Some ideas:
"My lawyer thinks that the only situation where a non-compete agreement would be useful, is when a former employee is actually engaged in competition with his ex-employer. Why doesn't this non-compete agreement mention anything about competition?"
"I do ${creative_hobby} in my spare time. Every now and then I make something worthwhile and sell it. Under this agreement, how do you propose I re-license my designs from you? What's the company's normal licensing policies? I mean, I probably need to raise my prices, can we negotiate a percentage for this deal?" -- "So you say that the company would never actually make claims on IP that is outside it's business area? Very good, I'll draft a new agreement that actually says so and we'll continue the discussion from there."
"Have you read this agreement? Would you sign it yourself?" (If he's stupid enough to actually do it, make sure his boss receives the signed document. It doesn't mean YOU have to sign anything.)
"Let's talk about our current agreement and the differences to the new agreement. The current agreement is BILATERAL, stating that intellectual property an employee creates during working hours [or something, better verify this!] becomes company property, and in compensation the employee receives a monthly salary plus certain bonuses. Right? Now this new agreement is very UNILATERAL, giving the company additional rights. What is your plan for giving the employees appropriate compensation?" Note that the agreement actually gives the company ALL rights the employee may have to ANY intellectual property. They are essentially buying your life. Also note that the less free time you have, the more valuable that time is for you and the less likely you are to sell it for money. The last free hour would therefore cost a lot.
"You say that this kind of agreement is common in the industry. As a matter of fact, this is the first time I've seen anything like this, and neither has anyone I've talked with (including all of Slashdot). But surely you have several examples on hand, so just point out another large company that requires employees to sign a similar all-compassing agreement, and we will be happy to continue the discussion."
"You say that people who want to continue working here must sign the agreement? Let's think about this for a moment. People have two choices, they can either sign or quit. I'm quite sure that top performers are able to find new jobs more easily than low performers, and they are also more likely to read and understand the new contract. My conclusion is that on average, top performers are less likely to quit while low performers are more likely to sign. Right? Mr. Alpha Nerd and Mr. Thought Leader, what are your thoughts on this?"
"You say that this is how it is and to stop complaining about it. Well, until the agreement is signed, this is pure fantasy and speculation. In order for people to join your fantasy, you need to use either carrots or sticks. We already established that if you try the stick, the best people will refuse and quit. Now bring out the carrots!"
You get the idea. Any reasonable manager would see the light after the first question.
This may sound stupid, but I'd suggest you start by simply calculating and estimating stuff in your head to a precision of two or three significant digits. Nothing fancy, just summing up your purchases in the grocery, estimating the monthly interest on a mortgage, estimating the size of a room etc. Make up the questions or pick ideas from the environments and situations you encounter. Make a point of doing two of these exercises a day, e.g. during your daily commute.
Over time (couple of years probably) this will give you a basic feel for numbers and also the ability to double-check answers. This is a fundamental skill that will make it much easier to pick up the geometry and calculus skills you are interested in.
It's not worth archiving everything. But what you do archive, you should archive properly and carefully. All interesting information falls into two groups:
Stuff to index and archive - Reports, newspaper articles, HOWTOs, manuals, books, specifications and other valuable and above all referencable stuff should be indexed and archived using the tool of your choice. Unfortunately, this is hard to automate and takes several minutes of your valuable time. Fortunately, this means that you won't have the time to archive all the useless crap, which naturally belongs in the second category...
Stuff to leave to Google - Just remember the terminology or jot down the relevant keywords in an e-mail to yourself. Then use Google again when necessary. No need to store the URLs, Google does it for you.
Indexing and archiving and maintaining their own bibliography is what researchers do to stay on top of things and there is no way around it (unless you are in a position to use your underlings for this purpose.) You may want to capture the author(s), date, title, URL, some keywords, a clickable or copyable path to your local PDF copy, and perhaps the abstract or executive summary.
Over time you will learn what to archive yourself and what to ignore. You will also find that for every handful of documents, only one is important and insightful and worth archiving while the others simply reference or paraphrase the original document. This is basically the 80/20 rule and it holds regardless of the subject area. -- Murphy's law states that you will only find this document after you've indexed all the others... but that's life for you.;)
I don't get why RPN is so popular amongst the supposed geek crowd. It's backwards from all the work you do on paper (or do you also write your equations down in RPN?). It makes it much more difficult to translate to english as well. Instead of the calculator conforming to the way you work, you have to conform to how the calculator works. Seems completely backwards to me.
Yes, that's because you have it backwards. Infix notation (used by TI and others) is an old convention that works well on paper but doesn't lend itself to working dynamically with mathematics. RPN conforms to how humans think and work.
RPN is very similar to graphical user interfaces. You take this one... and that one... and then you perform this action on them, and here's the result. And then you take the result and that other result and do this on them...
RPN lets you bring mathematical entities to closure as soon as you're finished with them. With infix you are forced to leave operations half-way, extending and extending the equation until with a final closing parenthesis you bring the whole equation to closure... i.e. you keep even the smallest details open until the bitter end. With RPN you can forget about those details and think about mathematical components, on a higher level of abstraction. The higher the abstraction level, the more area you can cover.
RPN is excellent when learning math, because you have to look at the equations from another angle, different from how they're written. This allows you to see more which hopefully allows you to build better mental models and processes that will be useful later.
By the way, I prefer TIs (Ti89 is like portable matlab), command line is cool for some tasks, C++ is nicer than Java, don't care for vi or emacs, and have an engineering degree.
I also have an engineering degree, but I prefer to do things efficiently and pragmatically. If I have to learn new things, so be it. RPN is well worth the initial investment of a few hours.
The product is a J2ME application that you install into your mobile phone. You activate the application in advance by entering a cryptographic key. To authenticate something, you start the application and enter your PIN code, then type in a challenge code given by the remote service (a web page, a VPN gateway, whatever). The application displays some details about the remote system and the transaction, then gives you a response code that you feed back into the remote system.
The application is totally generic (i.e. not personalized until you enter your activation code), uses only tested and tried cryptographic methods, and has been security reviewed by several (OK, two) independent companies. Although the demo is aimed for online banking, there's no reason why the product couldn't be applied to any other situation where reliable authentication is needed.
The product page itself is a little bare but there's more under Press Releases (between November 2005 and June 2006, I believe). There's e.g. a joint press release with UK security lab Qinetiq and an interesting video clip off the German TV news.
Slashdot Mirror
Lean IT is about delivering quickly and cheaply, Agile about delivering high value compared to the costs, devops about taking responsibility for your work. If you start with one of these methods and take it to its logical conclusions, you'll end up with something that isn't very far from the others.
The idea that you can start with a mishmash of all three is probably not productive - there's a kind of learning journey you have to go through - but I'm willing to change my mind if somebody delivers proof.
What do you mean, "not enough memory"? 640 kB ought to be enough for anybody.
You don't want to make it even more cumbersome to change the code, as it sounds like you are already struggling with the 10 Mloc codebase. So forget about having humans "approve" the changes.
What you want to do is make it easy to submit good code and difficult to submit bad code. This means that you will need the capability to quickly assess the proposed patch, for some definition of "good" and "bad". Computers are fairly good at this. In other words: test-first development, with automated testing on several levels.
Bug comes in, you write an automated user acceptance test that FAILS. Then you try to find and fix the bug. When the newly added test passes, the bug is by definition fixed. Add a couple of unit/module tests, and a couple of UATs for good measure. Rinse and repeat.
There's plenty of tools for this. All major platforms have the capability for programmatic reflection. Use e.g. Cucumber for the acceptance tests, and the relevant unit test framework for module/unit tests. In addition to the functional tests, try static analysis.
Is this an article about how the Windows 8 UI was designed?
Or about how they kept the world's population hostage with Clippy the Paperclip? I mean, when they heard Clippy was going to be removed from the next version of Office, around 350 million people upgraded straight away.
Or is it about how Microsoft is paying 500 million (USD, EUR, whatever) in fines every couple of years, in order to keep doing business as a software monopoly? That is probably the most brilliant crime by the Microsoft Digital Crimes Unit ever!
Learn to juggle! Seriously! I learned to juggle with three balls during a particularly stressful software project some 15 years ago. Nowadays when I feel blocked, I pick up three round objects and go somewhere else to juggle for a while. I haven't progressed beyond three objects but then again I'm not doing it for the fame and the money. :)
Juggling activates other parts of your brain than you (as a software engineer or IT guy) normally use. You can juggle as long as you like, ten seconds or ten minutes. The materials (e.g. stress balls, tennis balls, apples, oranges, whatever) are cheap and small. Does you good to get up out of that chair and stop staring at the monitor for a moment. If someone asks what you are doing, say that you're taking a minute to think about some small creative problem e.g. structuring the next three paragraphs you are writing, or looking for alternative ways to implement some feature. The learning threshold is admittedly steep, but the Internet should be full of tutorial videos by now. Also, juggling is a nice party trick, kids especially are fascinated.
Think of it as an off-screen microhobby...
--Bud
> It's a fact that OS/UI developers seem to believe that [something]
A seeming fact, then? Or an opinion?
> we generally need increasingly large displays [read: pixel counts] in order to restore focus on the application and to minimize the impact on screen and usability which the OS/UI claims.
Not at all. We generally need more and better modes of interacting with our phones and the apps running on them. You see, there is an upper limit to the physical size of a phone: it needs to fit into your pocket. And there is also a lower limit on the size of an UI element: your fingertip. Increasing the resolution only enables the device to show sharper text and more detailed pictures.
There are many "novel" or "trendy" interaction methods like swiping, pinching, multi-finger dragging, gestures and so on, that are not yet commonly used in mobile phones or mobile apps. Properly used, they can free up screen estate. For example, an app that supports pinching doesn't need on-screen zoom buttons.
Many if not all of these interaction methods can profitably be reserved for the system UI. If you replace the most common system UI functions with gestures, you can remove the status and system bars and free up the top and bottom part of the screen. The Android 2.x swipe-from-the-top action is a good example, as it allows the top status bar to become very narrow. However there is no reason to stop there.
> Android 2.x seeks to minimize the UI impact and it does a nice job of it. A minimal row of buttons
No it doesn't. The iPhone minimizes the UI impact by simply NOT having that row of buttons. The Nokia N9 uses swiping creatively to do away with even the physical buttons and touch areas that you find on Androids, iPhones and Windows Phones.
All of these phones, even the N9, still have a slim status area at the top. Jolla's Sailfish aims to do away with even that.
> What Ubuntu-phone is proposing is unintuitive and seeks to infringe on how an app can live on a device. Do. Not. Want.
So you say. Now, in the real world, what Unbuntu proposes is really going to make some if not all of the system areas redundant and give apps more control over the screen real estate.
What is intuitive, by the way? In this context something is intuitive if you can pick it up and use it without training. It's not even remotely synonymous with "whatever I've gotten used to", as you seem to imply.
Have you actually tried a swipe UI? I have been using a swipe-based phone (the aforementioned N9) for a long time now, and it just works. You can either take my word for it, or go and try it yourself before commenting further.
--Bud
"Remember that all models are wrong; the practical question is how wrong do they have to be to not be useful." (George E.P. Box and Norman R. Draper, Empirical Model-Building and Response Surfaces (1987), p. 74)
"One of the most insidious and nefarious properties of scientific models is their tendency to take over, and sometimes supplant, reality." (Erwin Chargaff)
I think that says it all, really.
--Bud
One wonders if they'll be turned off by Celine Dion music — a new type of shark repellent perhaps?
Oh yes, the "Celine Dion effect" is well known. For example, playing My Heart Will Go On in railway stations late at night will magically keep the stations empty from pickpockets, rapists and other miscreants and indeed any sentient beings except cockroaches. The high notes will first melt your earwax and then your brain. Cockroaches merely lose their orientation and walk into walls.
I don't see any reason why it wouldn't work underwater too. Unless of course the sharks fight back with lasers.
--Bud
> stupid_is writes with news that Duke Nukem Forever has now gotten a firm US release date: May 3rd.
Yes, but which firm?
> It will release worldwide three days later.
Release what?
I thought "DNF" stood for Did Not Finish.
--Bud
One element I pushed was that nobody was going to be interested in their kernel, regardless of what they did, and that conversion to Linux would eventually be necessary if they were not to continue to expend millions on re-inventing the wheel.
Not a good thing to push because the kernel is the interesting part of Symbian. It's power-tight and has real-time features, both of which are very nice features in a mobile communications device. Unfortunately it only runs on ARM. Linux on the other hand runs on everything. With Qt on top of both Symbian and MeeGo, there's nowhere Nokia can't go. (There's no guarantee they'll actually go there, but they *could*.)
--Bud
Ouch - this is the best that Hubble can do? The images show serious chromatic aberrations, with significant red-blue fringing on edges. What's worse is that the effect gets more pronounced as the camera moves around.
Given that the camera moves at relativistic speeds, the chromic aberrations are probably a relativistic effect and would of course get more pronounced the faster the camera moves. Another interesting side effect is that while for you the movie is over in a matter of minutes, someone observing you will feel that the movie takes too long, and incidentally also perceive you as significantly smaller.
Kids, don't try this at home!
--Bud
What was that again? Last time I checked, Darl McBride was busy terminating SCO. :)
--Bud
It seems that in some cases, whiskey can now be called an energy drink.
--Bud
I said nothing about the font handling process or font data formats. I said that the *results* are good. Sheesh.
If the Computer Modern font does not please your eyes, you can get any of the 35 standard PostScript fonts with one puny usepackage statement (e.g. \usepackage{times}). The procedure for installing arbitrary TrueType or PostScript fonts is a bit more involved but there are tools and walkthroughs available. See also http://www.tug.org/fonts/.
There are TeX forks like XeTeX that can handle modern digital fonts automatically.
--Bud
Except that in this case, you can bring out a magnifying glass and see the differences yourself. Kerning and layout is an art that has been perfected for centuries. For example, the visual weights of the letters must be accounted for. You can't just put letters on a line one after another and expect the results to be nice or even readable. TeX/LaTeX was designed to reproduce the implicit and explicit rules of text layout and kerning. It has a separate font rendering library called Metafont. The results are very good, so good in fact that many have been content to write front-ends that call TeX or LaTeX for typesetting.
MS Word was designed by engineers to dump letters in sequence on paper. Early versions were unable to kern at less than screen resolution (some 75dpi). Later versions shipped with TrueType fonts lacking proper kerning information. The results are not good. So bad, in fact, that people turn to other alternatives. Reading documents "typeset" by Word in Times New Roman hurts your eyes, just like listening to 96 kbps MP3:s hurts your ears.
Some reading, if you don't believe:
http://nitens.org/taraborelli/latex
http://robgoodlatte.com/2007/07/24/3-examples-of-bad-microsoft-word-typography/
--Bud
The notion that the writer is agnostic of the typesetting procedure and methods with LaTeX is a complete lie. I've never had to worry about ratios, measurements, indentations, word-per-line, empty pages and other problems as I have in LaTex.
This doesn't reflect my experience at all. The general settings are tuned once and for all in the preamble, you just focus on the writing and enjoy the results. You don't need to know anything about the typesetting procedures and methods.
For example, my 93-page thesis was typeset as \documentclass[a4paper, 12pt, titlepage, oneside, parskip]{scrreprt}. All settings are global, located in the preamble or at the very start of the body. Aside from some words that had to be explicitly hyphenated, there is absolutely no "tuning" of any kind in the main text to avoid orphans, widows, weird word-per-line counts, etc. There are no orphans, widows or weird word-per-line counts. The document looks good, just like the dozens if not hundreds of LaTeX documents I've written previously. (Looks only, mind you, I'm not vouchsafing for the contents. :))
If LaTeX inserts empty pages for you, you are probably using a document format which allows page padding before chapters. If LaTeX allows weird word-per-line counts, probably the page or column is so narrow that it's impossible to do a good job (without tuning the penalty variables). And so on.
Above all, LaTeX is totally deterministic. You make a change and it stays changed. And it works nicely with various version control systems, so you can do major edits without fear of losing your work, visual diffs, merges, etc.
--Bud
So could LaTeX be retrofitted to use TrueType for everything? Probably.
Certainly. XeTeX is LaTeX with modern fonts and unicode support.
--Bud
There's an OSS Matlab clone called GNU Octave, see http://www.octave.org/. It's mostly compatible with Matlab. I've been using it for handling larger datasets or maths-heavy stuff. Works fine. --Bud
Basically, this is how it goes:
Every team or group in the company is made responsible for (a) writing down their own values and processes on a Wiki page and (b) listing their obligations to other teams. The former is called the "team charter" and the latter a "service level agreement". Tell them that they will be required to sign these charters and agreements later. They are of course allowed to cooperate with other team, e.g. the testers might need to create a common template, or talk to the software development team about their obligations. Make clear what you expect to see, then ask them to come to you to get it accepted when they're done.
Length, detail and quality doesn't really matter. One page of text will do a long as it covers most things. E.g. "We are software professionals and like other people's code to be well designed, well written, well documented and not too optimized. In return we will write our own code to that spec. [...] We believe that domain knowledge is improved by creating throw-away prototypes and mockups. [...] For defects we use Bugzilla; the guy who currently owns the Bug Fixing Hat is responsible for performing triage daily on the new bugs. For version control we use Subversion; the guy who has the Builder hat is responsible for creating fresh weekly builds..." etc etc.
Measure the number of teams that have posted their team charters and service level agreements in the Wiki. Give a small goodie (toy, bonus) to the teams when they complete the charters and SLAs. Post the number of teams and the percentage of all teams in the company's internal newsletter. When there are only a few teams left, post the names of these teams in the "hall of shame".
Pick a handful of random teams. Visit them and make them explain what they have written and the rationale behind it. Have they listed all team that depend on them? Are they doing stuff that's not in the charter? Does the charter contain outdated practices? If they say they're happy with the charter, print it and make them sign it. If they don't want to sign it because they're not done yet, make them update it until they are happy with it.
--Bud
[...] first have to go to a retail store [...] they will be able to download one of just 37 albums available through the service, including Britney Spears' "Blackout" and Barry Manilow's "The Greatest Songs of the Seventies."'"
Uhh... great artist selection, there. If I have to walk down to the retail store and then choose between Britney and Barry Manilow, I would rather save my hard-earned money.
Within a couple of months Sony will "accidentally" leak the sad numbers of their non-DRM trial to select members of the press, who will then write scathing opinion pieces about how the rampant piracy is so widespread that even removing DRM can't help the music industry.
--Bud
Assuming that you enjoy your current job and are willing to fight this, you should try social engineering. Apparently some people in the company are trying to bully you into signing over your copyrights. The way to handle this is to bring it out into the open and make the bully the laughing stock.
Discuss the agreement with your colleagues over coffee and/or lunch. Collect a bunch of alpha geeks and other thought leaders among your co-workers. As the representatives for a group of outraged employees (i.e. yourselves, unless the whole department is outraged), brainstorm some tricky questions and schedule a meeting with the guy who tries to enforce the agreement. Then walk in to his room, sit down and start asking tricky/stupid/self-evident questions. Some ideas:
You get the idea. Any reasonable manager would see the light after the first question.
--Bud
This may sound stupid, but I'd suggest you start by simply calculating and estimating stuff in your head to a precision of two or three significant digits. Nothing fancy, just summing up your purchases in the grocery, estimating the monthly interest on a mortgage, estimating the size of a room etc. Make up the questions or pick ideas from the environments and situations you encounter. Make a point of doing two of these exercises a day, e.g. during your daily commute.
Over time (couple of years probably) this will give you a basic feel for numbers and also the ability to double-check answers. This is a fundamental skill that will make it much easier to pick up the geometry and calculus skills you are interested in.
--Bud
It's not worth archiving everything. But what you do archive, you should archive properly and carefully. All interesting information falls into two groups:
Indexing and archiving and maintaining their own bibliography is what researchers do to stay on top of things and there is no way around it (unless you are in a position to use your underlings for this purpose.) You may want to capture the author(s), date, title, URL, some keywords, a clickable or copyable path to your local PDF copy, and perhaps the abstract or executive summary.
Over time you will learn what to archive yourself and what to ignore. You will also find that for every handful of documents, only one is important and insightful and worth archiving while the others simply reference or paraphrase the original document. This is basically the 80/20 rule and it holds regardless of the subject area. -- Murphy's law states that you will only find this document after you've indexed all the others... but that's life for you. ;)
--Bud
I don't get why RPN is so popular amongst the supposed geek crowd. It's backwards from all the work you do on paper (or do you also write your equations down in RPN?). It makes it much more difficult to translate to english as well. Instead of the calculator conforming to the way you work, you have to conform to how the calculator works. Seems completely backwards to me.
Yes, that's because you have it backwards. Infix notation (used by TI and others) is an old convention that works well on paper but doesn't lend itself to working dynamically with mathematics. RPN conforms to how humans think and work.
RPN is very similar to graphical user interfaces. You take this one... and that one... and then you perform this action on them, and here's the result. And then you take the result and that other result and do this on them...
RPN lets you bring mathematical entities to closure as soon as you're finished with them. With infix you are forced to leave operations half-way, extending and extending the equation until with a final closing parenthesis you bring the whole equation to closure... i.e. you keep even the smallest details open until the bitter end. With RPN you can forget about those details and think about mathematical components, on a higher level of abstraction. The higher the abstraction level, the more area you can cover.
RPN is excellent when learning math, because you have to look at the equations from another angle, different from how they're written. This allows you to see more which hopefully allows you to build better mental models and processes that will be useful later.
By the way, I prefer TIs (Ti89 is like portable matlab), command line is cool for some tasks, C++ is nicer than Java, don't care for vi or emacs, and have an engineering degree.
I also have an engineering degree, but I prefer to do things efficiently and pragmatically. If I have to learn new things, so be it. RPN is well worth the initial investment of a few hours.
--Bud
Sorry for this blatant plug but I believe it's quite relevant to the discussion.
The company I work for has an authentication product that's more secure than hardware tokens (SecurID) and one-time password sheets.
The product is a J2ME application that you install into your mobile phone. You activate the application in advance by entering a cryptographic key. To authenticate something, you start the application and enter your PIN code, then type in a challenge code given by the remote service (a web page, a VPN gateway, whatever). The application displays some details about the remote system and the transaction, then gives you a response code that you feed back into the remote system.
The application is totally generic (i.e. not personalized until you enter your activation code), uses only tested and tried cryptographic methods, and has been security reviewed by several (OK, two) independent companies. Although the demo is aimed for online banking, there's no reason why the product couldn't be applied to any other situation where reliable authentication is needed.
The product page itself is a little bare but there's more under Press Releases (between November 2005 and June 2006, I believe). There's e.g. a joint press release with UK security lab Qinetiq and an interesting video clip off the German TV news.
Thanks for listening!
... Is that the sound of my karma evaporating?
--Bud