As other have pointed out, you have the opposite meaning of NIH.
A bigger point that needs to be made though is why strategies like google's are slightly misguided. Third party software can be successfully integrated into an internal system. The challenge is performing the proper due dillegence on the software and making sure it meets your needs in terms of functionality, sustainability, support, and all the other factors that tend to be ignored during the purchasing phase. When the right commercial software is deployed, it can save hundreds of thousands of dollars (think the cost of having two or three in-house engineers working on it for 6 months).
The problem most software engineers have performing good due diligence is that most understand how the software was written and know they could write it themselves. They confuse this with the idea that they _should_ write it themselves and come up with all sorts of reasons why it will be good to have the code in house (that is, invented here). At this point, due diligence has turned into evaluating an existing product against the aspirations of the developer. Good managers know now to keep these developers in check, bad managers don't and end up reinventing the wheel.
The problem then becomes one of lost opportunities. What novel software that would truly benefit the company's bottom line was lost because the developers spent all their time writing something that already existed?
To illustrate, about 10 years ago I worked at the online division of a GIS company (that would later be bought by AOL). Our extremely talented Java team was able to convince management JavaDoc was inferior and they could develop a better version. Two engineers spent at least three months hammering out a documentation system for Java (that's 6 man months, 100 man years in Internet time) for a company who's entire codebase was primarily C++. What was lost here? Well, I mentioned the talent in the team. The Java client that was put on the back burner was pretty much equivalent to what Google Maps is doing today, but it was never quite finished.
"I like Assembler. There's something about interacting intimately with your target hardware. It's a shame that it's no longer feasible with today's variety of hardwar"
A minor observation about the feasability of working with the target hardware: the two most popular instruction set architectures for commidity hardware, PowerPC and IA-32, have both been stable since the mid 90s. The programming guide for PowerPC processors is still pretty much the same document as it was in 1996, around the same time the PowerPC ISA was defined. IA-32 has undergone some changes with each new major processor family, but is still backwards compatible at the instruction level with processors released in the 80s.
Contrast this with high-level (i.e., non assembly languages). Java has undergone a few major revisions in its 10 year lifespan. C++ has yet to have a compiler that fully implements the spec (think export and the really fun template games). Scripting languages are constantly evolving and sometimes aren't backwards compatible over a 4 year period. Then there's the Microsoft switch to.Net that invalidated billions of lines of VB and VC++ code. Compared to these languages, machine code is incredibly stable and portable (across processor iterations, at least).
Of course, there are architecture considerations for squeezing performance out of code. But, again, these haven't changed much in the last 10 years, either. The memory bus is still the bottleneck and you still get 50-80 instructions for 'free' on each load, even if you're not filling the pipeline completely. If you are doing something that isn't memory bound, it's not that hard to look up the instruction latencies in the manual and code things up to fully utilize the processing units and keep the pipline full. At least, it's no more difficult developing scalable EJB applications for your favorite web application engine...
"We're geeks. We learn the most efficient way to do things because that is in our nature. Most people won't bother. They just want to get the damn job done, even if they end up wasting more time in the long run."
I've spent a good deal of time in both Word and LaTeX and hear this all the time from geeks who still use LaTeX for everything.
It's worth pointing out that LaTeX is not the most efficient way of doing most documents. It is very good at handling citations, but that's it. For everything else, it is inefficient compared to a word processor. And, word processors could have excellent support for citations, if there was a market for it (a few thousand acadmics who expect all software to be free is not a market).
To back up that statement a bit, consider the process of createing a document in LaTeX. Usually, you open up a text editor, write your document using LaTeX's markup language and 'compile' the document. Once its compiled, you look at it in xpdf, find the layout/grammar bugs, and repeat. At some point, you start breaking the document out into sub-files that contain sections or complex equations, and it's not uncommon to have a main.tex file that builds the final document, usually with the aid of a makefile.
Given that workflow, can you see any reason LaTeX would appeal to geeks? Think about it. It's exactly the same way we learned to develop code in school! Edit, compile, run, subroutines, makefile. It _appears_ to be the most efficient way because it maps nicely to something we do on a regular basis. But, most people stopped using text editors and makefiles when IDEs matured. Here's the secret: Word processors are the IDEs of layout.
Let's look a little deeper. To do any basic formating in LaTeX, you have to surround your text with markup. That's extra typing, which is not terribly efficient. And, when you're reading heavily marked up text, you have to filter out the markup to make sense of things. To catch any layout errors, you rely on a viewer for feedback, which adds a roundtrip between the viewer-editor-web. I threw Web in there, because if you've ever tried to do any _real_ layout in LaTeX, you'll need to hunt down the secret incantation that solves your problem. Then there's spell checking. Sure, FlySpell is nice in Emacs, but it's hardly state of the art. Grammar checking? Don't even thing about it (yeah, I know this is of limited usefulness, but it helps sometimes).
Now, go back to a word processor. There's no extra markup to type, layout problems can usually be resolved by tweaking a few settings available from the context (right-click) menu, there's no compile-debug cycle. Styles (even in Word) can be defined to change the look of a document instantly (as long as you know how to use them, but the same is true for LaTeX). For complicated documents, word processors do start to show their rough edges. But, LaTeX doesn't scale that well, either. And, that's a customer issue, most people just don't do enough complicated layout for it to matter. Output formats? "Save as..." (and don't try the human readable claim - how often do you really go back and edit things outside the program you created them in? Be honest.)
So, next time you find yourself claiming that LaTeX is the best way to do everything, take a step back and make an honest evaluation of your workflow.
I've been using a MOTU 2408mkII as my main audio capture device for similar purposes. The one thing I've found is that it's worth putting a decent mixer in front of it to get all the signals up to a line level. The on-board level adjustment in the MOTU appears to be all software controlled (think digital zoom on a camera) and it was difficult to get consistent signals from the various mics and direct boxes I used. I use the inserts on the Mackie to send the signal to the inputs on the MOTU.
The different in raw sound quality is noticable. Without "cleaning" the signals first, I rarely had enough of a signal to work with and the MOTU algortihms for adjusting the level just weren''t good enough for poor signals.
I use a custom Web app I wrote in Python using IMAP to talk to our mail server. It's great for reading email. I also use Yahoo mail from the Web browser for my Yahoo account, but lately they've added a lot of Javascript features that use up the available memory and make the experience less enjoyable. Of course, this is all using the Web browser in the 2.x firmware.:(
We initially intended to do a homebrew version of the Mail app (the Web app was supposed to be a UI prototype), but upgraded our PSPs to 2.x before realizing the problems the upgrade caused. Of course, there was also the catch 22 with the browser - we needed 2.x for the browser to prototype but that made homebrews difficult.
Cleaning the mail app up and posting it online is on my short list of projects. It'll show up on my Web page sometime in the next few months (www.osl.iu.edu/~chemuell/downloads.php).
I found this story about 18 hours after watching the Battlestar Galactica miniseries on a PSP on a plane. So, there's at least one person watching movies on the PSP. Of course, I ripped it to a memory stick and didn't watch it from UMD (in fact, I've never watched a UMD movie).
I'm really disappointed in Sony for their positioning of the PSP. It has so much more potential than as a vessel for movie sales. I take it with me whenever I travel and use it as my primary entertainment, Web, and email device (using a home-grown Web mail app with a UI designed specifically for the PSP - one of a few Web apps I've developed to deliver content in PSP-sized Web pages (sorry, no links as my server can't handle the/. effect)). In fact, at the conference I just attended, there was "contention" for my laptop and I was stuck with just the PSP. It actually turned out to be adequate (though a chat client would have been nice). Text entry was a little annoying, but that's about it.
I really wish Sony would get on the ball with a suite of productivity/connectivity apps. They don't need to be complex, just enough to talk to IMAP/Exchange/iCal/Chat and get me the info I need one the road (I'm not in sales, so my needs are modest). Or even just offer an open development kit so those of us with fulfilling day jobs can hack together little PSP tools.
Productivity + Games + (non-UMD) Movies + Music in one small device is great for travelling...
People reject OpenOffice and reject even Mac, because they don't know any different. They have been "programmed" to use Microsoft Windows, therefore, until they are told different, they will continue to use Microsoft Windows
On the other hand, computer geeks reject Microsoft Windows because they don't know any different.
The best travel games I've found for the Gameboy Advance are the Advnace Wars series. I've spent entire trans-Pacific flights playing the longer campaigns. If only the airlines would build link cables into the seats for playing random passengers...
A close second lately has been Lumines on the PSP. Trying to get higher scores on the 60 second mode makes time fly (Did I really just play 80 rounds???).
Just to reinforce the point that ActiveX/COM/.NET are important: there is no equivalent technology on Unix platforms that easily enables developers to share components across languages. One reason Windows is so successfull in the workplace is that it is trivial for a casual programmer to glue together many powerful components to create custom business applications.
The closest Unix comes is TCL and Python. These are the standard glue languages on Unix. But, using Python on Windows with COM really exposes how far behind Unix is. On Windows, you immediately have programatic access to almost every program installed on the computer. Its trivial to include an Excel spreadsheet in an application that loads data from a Web service, mixes it with a local Access database and uses VTK to render a fancy visualization. The same task on Unix is possible, but requires more effort and the UI controls are (for lack of a better term) clunkier (and that's all the user really cares about).
The Linux crowd really should put aside their predjudices and spend a few months writing Windows applications, just so they can understand what they're missing.
I recently returned to school to work on a PhD after working in industry for seven years. Over the last two years, I've been involved in a number of software engineering projects with scientists and just recently helped hire a software engineer to "replace" me.
Here are some things I've learned:
1) If you're going for a degree, don't mix research and software engineering projects. You'll find yourself spending too much time as a software engineer and not enough developing your research skills. It's ok to have both types of projects, even as part of your official research, but keep the software projects separate from the pure research ones.
2) The only two deadlines that matter are grant deadlines and class deadlines. This is in contrast to working in industry, where there are often many deadlines with many people relying on you to meet them. Research and even academic software development works at a different pace. For the first year, I worked at an industry pace and nearly burned myself out. Then I realized that no one else was working at that pace and I could actually take my time and do things 'right'. This has greatly improved the quality of software I write and helped me hone my research skills by allowing myself the time to explore the problem completely.
3) Everyone is pretty much equal when it comes to intelligence. An earlier poster noted that post docs and other PhDs tend to be arrogant. This is true, but as far as I can tell it's really just a defense mechanism. They're often as itimidated by you (coming from industry) as you are of them. Ultimately, while I've found people's knowledge can vary widely, most everyone you'll work with has the same level of intelligence. And, once you get past the facades, academics are a lot of fun to work with. (and though they'll rarely admit it, they enjoy learning from people with industry experience)
4) The benefits are nice. At my school, the support employees earn competitive salaries ($50k/yr for junior programmers), get 6 weeks of vacation and good health coverage. Couple this with relaxed work schedules and it makes for a nice job.
5) You can't be a full time employee and student at the same time. For legal and practical reasons, pick one or the other and focus full time on it. You'll be saner in the long run. Everyone I know who consults on the side is overwhelmed with work and can't really enjoy the extra money they make. Of course, if you have a family to support, you may have to make some sacrifices (and I'm not talking about the kids).
I think what the original poster was referring to with 'micro-RNA' was recent discoveries like siRNA and other forms of RNA that play important roles in the whole process but are never converted to protein.
My best understanding of siRNA's effect on genes (please correct me if I'm wrong) is that small RNA fragaments are trascribed from the DNA and actually bind to mRNA stands, inhibiting their expression. The coding regions for the siRNA strands are not the in the same location as the original gene that they help regulate, so it's difficult to find them (they were only discovered in the last 10 years) and difficult to know when they're affecting for the behaviour of a gene.
siRNA is only one example of the not-so-clean relationships between DNA/RNA/protein. Instead of the simple central dogma, it's turning out that there are many more complicated interactions at each level of abstraction (to use a CS term) and between levels.
So, while [genome sequencing|protein folding|etc] were all tought to be the grails at different times, they're all just turning out to be pieces of a larger puzzle.
I suspect that the real grail will turn out to be not one technology or algorithm (e.g. whole genome shotgun, protein folding) but a consistant model that ties them all together and gives biologists a solid theoretical framework to work with.
This definately appears to be the case. I read the post and hoped that they were actaully streaming video to the squeezebox and using some clever server hack to modulate the video signal and send it out over one of the audio channels. This is not the case at all. They're just using the Squeezebox as the remote control for a PC connected to the TV.
While this isn't as exiciting, it's still a nifty hack. One of the great things about the Squeezebox is that its form factor and UI enable it to integreate seamlessly into an existing AV system. Not only does it look like an AV component, but it acts like one too. The UI is simple and it's easy to control with the remote control.
Other hacks let you use the Squeezebox to check weather and stock quotes. If your PC is already connected to your computer and you have a Squeezebox, this hack lets you control your audio and video using one remote and the simple display provided by the Squeezebox. It's looks like it's a natural way to combine two similar things (audio and video) under one UI, even though the data paths are completely separate.
So, even though it's not a streaming video hack, it's still a nifty hack.
(it's worth noting that I'm a Squeezebox owner and love the hacks that people have done for it - the few times I've had a cool idea for it, someone's already done it! It's a great community and it's great that Slim Devices has opened up the software for tinkering.)
Yup, that's the one. We have one in our vis lab and you need a magnifiying glass to see the pixels (at least with my eyes).
Still not quite the resolution of printed paper (the T221 is around 200 DPI), but better than a pencil.:) Now if they just made it the size of a whiteboard...
I'll second this. I'm doing my second round of school (PhD after years of working) and am using a clipboard and paper instead of my notebook (computer) for notes. I had bought a nifty Vaio to take notes on and quickly abandoned it in favor of the tried and true pen(cil) and paper approach.
Three other advantages are:
1) Paper notes don't disappear when your hard drive crashes 2) The resolution of paper and ink is still better than computer monitors (save for the IBM Bertha display) 3) Layout flexibility - it's much much much easier to just draw something on paper inlined with your notes than it is to do it in a word processor (though ASCII art in Emacs can be fast;) ).
Get a good notebook (or desktop) computer for other uses, but for taking notes, experience has taught me that you still can't beat a pen and paper.
Back in '97 or so when Hotmail came out, I couldn't understand why anyone would use it. All you have to do is run a mail daemon somewhere or just use your email address from your ISP, right? Who needed Web-based email? Turns out, everyone did.
At the same time, I had a brainstorming session with some friends and we thought of things that we had used in college (early 90s) that hadn't made it out to the 'real' world yet. 'talk' was the one thing we all agreed on that hadn't made it big that we found indispensible. Of course, we also thought that all people needed to do was start using 'talk' or 'ntalk' or irc, so there wasn't really an opportunity there. Turns out there was an opportunity, almost as big as email: instant messaging. Same idea, different implementation. Bummer.
The point is, while some things seem obvious and even trivial for the geek, they are often completely inaccessible to the average user. This is not a fault of the user or the technology industry, it's just the way things are.
I read the Wired article in print a few weeks ago and viewed it from this perspective. I thought it was great and full of good ideas.
Having developed extensively for *nix and Windows, I have found MSDN and Knowledge Base to be extremely thorough and useful. Both draw from the extensive collection of articles written by the MS devloper community to provide clear answers and how-tos (lower-case:) ) on just about every topic related to Windows development.
I know this thread is a pat on the back for the HOWTO's, but it shouldn't be used to spread FUD about MS's alternative.
-Chris
Re:Why parallel processors aren't common
on
Grid Processing
·
· Score: 3, Insightful
Scientific and financial computing, especially modelling and simulation, are where parallel computers can make a difference.
Many of the approaches to these problems take the form of a grid of elements that have local and possibly non-local interactions with each other. Each processor gets a subset of the points to work with and has to communicate with the neighboring processor's memory space to get information about neighboring points.
In a cluster, handling the points at the edges (or any non-local effects) requires a network and possibly disk request. Compared to local memory, this is incredibly slow and can temporarily starve the processor.
Big iron parallel systems address this by giving more processors access to the same memory and other shared resources, avoiding the costly network requests.
Of course, the current super computers (ASCII *, etc) are all clusters, just with incredibly fast network connections.
1. Calling Marvel's Silver Age comics "the most famous run of comic books in history" is a highly subjective and arguably mistaken statement. More famous than the early years of DC, with Batman and Superman? I don't think so.
This reminds me of my comic book days in the late 80s and early 90s when there were Marvel readers (X-Men, Spider Man), DC readers (Frank Miller, Sandman), and the indies (Cerebus, early Groo, etc). Each readership had a very myopic view of the world and was convinced their publisher was the most important.
For Marvel people, the Silver Age was when comics came of age. DC people pointed out that Superman and Batmen essentially created the industry and the indies suggested that everything up until then was crap (with the odd exception of X-Men, which everyone seemed to like). It was silly then and is silly now. A real, unbiased history that covers all publishers and ages would be nice. Does one exist?
As for myself, I'm a Barks man. Nothing beats his early Four Color epics.
From a geeky, awe of nature, just sheer beauty perspective, nothing beats Yosemite. Sure, it's crowded, but with a backpack, the crowds are easy to avoid.
Close second: The Grand Canyon. An hour is all you'll need, but it will be one of the more awe inspiring hours of your life.
If you really need a geek perspective before moding the parent up, think geology. These are two of the most amazing examples of geology on the planet.
I should've qualified my last post a bit by stating that the data visualization I've been involved with is primarily scientific visualization. I have also been developing Web based vis apps since 1997, so I understand the challenges well. In this domain, the sub-sampled data sets are still large and the cost of resampling can be high. Thus, it is important to get as much data to the client as possible to perform meaningful interactive analysis.
It is also often the case that when the user selects client side data, that data needs to be processed before it is re-rendered, a task not well suited for JavaScript and DOM-based data structures. Putting all the processing on the server tends to defeat real interactivity - 1 to 10 second delays are not acceptable when the user is trying to explore the data (note that this is a problem with Web apps in general, not just SVG apps).
smallpaul:...That's a classic complaint. Features I don't use are bloat. We need more features that I will use...
I never said I don't use the features. My complaint with SVG is that it's growing too fast for developers to keep up with it. It's been tough enough to get a working SVG viewer that supports the first few versions, let alone one that supports the most current. With no one working on the same version and the language developers adding new features, there hasn't really been time for anyone to figure out what should be in the language and what should be extensions (though the new extensions framework holds promise for helping out here). It's quickly becoming a jack-of-all-trades, master-of-none.
The is a real need for a consise vector graphics language, as both a Flash replacement and a tool for data graphics. I'm still holding out hope that SVG will mature into this language.
SVG has a long way to go before it will be suitable for data visualization. Most real world visualizations are based on large datasets and require a certain degree of interactivity. Both of these are possible using SVG. However, coding up an interactive application using JavaScript and the DOM model favored by the SVG designers is a non-trivial task.
A typical data set may contain 10,000 or more elements (e.g. financial analysis, temperature/forcast data, usage stats for a medium size web site, marketing data for a product line). Immediately, this requires a DOM tree with at least that many nodes. Given that each node requires a certain amout of meta-data and a containment heirarchy, the amount of data that needs to be transferred between the client/server, parsed, and managed in the browser grows quickly.
Ignoring the physical challeges of using DOM, there is also an abstraction challenge: Not all data fits nicely into the tree/scene-graph paradigm embraced by SVG. Of course, data can be transformed to use this model, but manipulating the data will be much more challenging.
Assuming a suitable DOM representation of the data exists, the next challenge is developing the JavaScript to allow the user to explore and manipulate the data. With no real package support and no built-in way to manage a large code base, JavaScript is not the ideal language for developing reusable vis code.
Before data visualization becomes commonplace in SVG browsers, another abstraction will need to be built on SVG that addresses the specific needs of the data vis community. This could be in the form of libraries that abstract the SVG frameworks with data vis APIs or another XML dialect that can be transformed into SVG.
I'm holding out hope that the SVG community will slow down on the feature creep and architecture bloat and focus on developing applications with the currect standard. Only by stepping back and trying to use the current system will the architects of SVG know what's missing and what needs improvement.
I work for a biotech developing their informatics syste, and have been heavily exposed to the challenges of working with chemical and biological data. And, I will be starting work on a PhD in CS focusing on these areas in August.
A quick note, I use the more general term 'life sciences' to denote the field that this work affects. While chem, bio and medicine are traditionally seperate disciplines, the computational problems are similar and shouldn't be forced into the old categories.
The biggest challenge currently facing both people attempting to solve problems in the life sciences using computers and those trying to implement computers using organic materials is the lack of mathematical and computational models to describe these systems.
Step back 50 years to the early days of computing. Computers were designed and envisioned as equation solvers and theorom provers (gross simplification, but bear with me). The physical sciences naturally adapted to computers since most of their theory is written using the language of mathematics. These fields helped push high-performance computing to where it is today and in doing so, molded the field to solve math-based problems.
During the same time period, the life sciences were starting to understand DNA. With a strong tradition of wet-lab and notebook based work, computers were essentially ignored. This changed somewhat with data aquizition systems in the 70s and 80s, but to this day, most analysis is still done on paper or in generic spreadsheets, using printouts from data systems (I see this every day).
On the modelling side, accurate mathematical models for even the simplest chemical and biological processes do not exist. While there's an obvious mapping of DNA to bits, no one has been able to do anything useful other than similarity searchers (which are rooted in math). The 'obvious' solutions to most problems (eg, protien folding) are generally NP-Hard and simplifications tend to yeild poor results that are not consistent with nature even for the simplest datasets.
Thus, the challenge in working with life sciences problems lies in the lack of a mathematical and computational system that can be used to explore the problems. Current research into linked systems (networks) and agent-based systems appear to be promising areas, but they quickly run into the same computational limitations of modelling life sciences problems - ie, they grow too big too fast.
Note that this discussion has left out the data analysis and processing problem (traditional bioinformatics), but it's worth mentioning that many of the same challenges exist. With no theoretical foundation for the data, it is hard to come up with a meaningful interpretation.
So, it appears that what is needed is not more articulation of current mathematical and computational models, but rather a different theoretical framework to work with. As mentioned, networks and agents brush this surface as haves chaos, cellular automata, complexity, neural nets, and most other 'fun' ideas of the last 20 years. Wolfram attempted to and has probably failed at providing a new framework to work within, but others are still looking and his ideas will hopefully lead to other insights towards this end.
The key here is that it will probably not be based on predicate logic and only implementable on Turing machines in ways that make it non-computable. So, a completely new system of logic will be required and a new model for computers.
Once this is in place, then life sciences problems will be accessible computationally. In the meantime, there are still lots of math-based problems that our current models will help sovle.
Slashdot Mirror
As other have pointed out, you have the opposite meaning of NIH.
A bigger point that needs to be made though is why strategies like google's are slightly misguided. Third party software can be successfully integrated into an internal system. The challenge is performing the proper due dillegence on the software and making sure it meets your needs in terms of functionality, sustainability, support, and all the other factors that tend to be ignored during the purchasing phase. When the right commercial software is deployed, it can save hundreds of thousands of dollars (think the cost of having two or three in-house engineers working on it for 6 months).
The problem most software engineers have performing good due diligence is that most understand how the software was written and know they could write it themselves. They confuse this with the idea that they _should_ write it themselves and come up with all sorts of reasons why it will be good to have the code in house (that is, invented here). At this point, due diligence has turned into evaluating an existing product against the aspirations of the developer. Good managers know now to keep these developers in check, bad managers don't and end up reinventing the wheel.
The problem then becomes one of lost opportunities. What novel software that would truly benefit the company's bottom line was lost because the developers spent all their time writing something that already existed?
To illustrate, about 10 years ago I worked at the online division of a GIS company (that would later be bought by AOL). Our extremely talented Java team was able to convince management JavaDoc was inferior and they could develop a better version. Two engineers spent at least three months hammering out a documentation system for Java (that's 6 man months, 100 man years in Internet time) for a company who's entire codebase was primarily C++. What was lost here? Well, I mentioned the talent in the team. The Java client that was put on the back burner was pretty much equivalent to what Google Maps is doing today, but it was never quite finished.
-Chris
"I like Assembler. There's something about interacting intimately with your target hardware. It's a shame that it's no longer feasible with today's variety of hardwar"
.Net that invalidated billions of lines of VB and VC++ code. Compared to these languages, machine code is incredibly stable and portable (across processor iterations, at least).
A minor observation about the feasability of working with the target hardware: the two most popular instruction set architectures for commidity hardware, PowerPC and IA-32, have both been stable since the mid 90s. The programming guide for PowerPC processors is still pretty much the same document as it was in 1996, around the same time the PowerPC ISA was defined. IA-32 has undergone some changes with each new major processor family, but is still backwards compatible at the instruction level with processors released in the 80s.
Contrast this with high-level (i.e., non assembly languages). Java has undergone a few major revisions in its 10 year lifespan. C++ has yet to have a compiler that fully implements the spec (think export and the really fun template games). Scripting languages are constantly evolving and sometimes aren't backwards compatible over a 4 year period. Then there's the Microsoft switch to
Of course, there are architecture considerations for squeezing performance out of code. But, again, these haven't changed much in the last 10 years, either. The memory bus is still the bottleneck and you still get 50-80 instructions for 'free' on each load, even if you're not filling the pipeline completely. If you are doing something that isn't memory bound, it's not that hard to look up the instruction latencies in the manual and code things up to fully utilize the processing units and keep the pipline full. At least, it's no more difficult developing scalable EJB applications for your favorite web application engine...
-Chris
"We're geeks. We learn the most efficient way to do things because that is in our nature. Most people won't bother. They just want to get the damn job done, even if they end up wasting more time in the long run."
I've spent a good deal of time in both Word and LaTeX and hear this all the time from geeks who still use LaTeX for everything.
It's worth pointing out that LaTeX is not the most efficient way of doing most documents. It is very good at handling citations, but that's it. For everything else, it is inefficient compared to a word processor. And, word processors could have excellent support for citations, if there was a market for it (a few thousand acadmics who expect all software to be free is not a market).
To back up that statement a bit, consider the process of createing a document in LaTeX. Usually, you open up a text editor, write your document using LaTeX's markup language and 'compile' the document. Once its compiled, you look at it in xpdf, find the layout/grammar bugs, and repeat. At some point, you start breaking the document out into sub-files that contain sections or complex equations, and it's not uncommon to have a main.tex file that builds the final document, usually with the aid of a makefile.
Given that workflow, can you see any reason LaTeX would appeal to geeks? Think about it. It's exactly the same way we learned to develop code in school! Edit, compile, run, subroutines, makefile. It _appears_ to be the most efficient way because it maps nicely to something we do on a regular basis. But, most people stopped using text editors and makefiles when IDEs matured. Here's the secret: Word processors are the IDEs of layout.
Let's look a little deeper. To do any basic formating in LaTeX, you have to surround your text with markup. That's extra typing, which is not terribly efficient. And, when you're reading heavily marked up text, you have to filter out the markup to make sense of things. To catch any layout errors, you rely on a viewer for feedback, which adds a roundtrip between the viewer-editor-web. I threw Web in there, because if you've ever tried to do any _real_ layout in LaTeX, you'll need to hunt down the secret incantation that solves your problem. Then there's spell checking. Sure, FlySpell is nice in Emacs, but it's hardly state of the art. Grammar checking? Don't even thing about it (yeah, I know this is of limited usefulness, but it helps sometimes).
Now, go back to a word processor. There's no extra markup to type, layout problems can usually be resolved by tweaking a few settings available from the context (right-click) menu, there's no compile-debug cycle. Styles (even in Word) can be defined to change the look of a document instantly (as long as you know how to use them, but the same is true for LaTeX). For complicated documents, word processors do start to show their rough edges. But, LaTeX doesn't scale that well, either. And, that's a customer issue, most people just don't do enough complicated layout for it to matter. Output formats? "Save as..." (and don't try the human readable claim - how often do you really go back and edit things outside the program you created them in? Be honest.)
So, next time you find yourself claiming that LaTeX is the best way to do everything, take a step back and make an honest evaluation of your workflow.
-Chris
I've been using a MOTU 2408mkII as my main audio capture device for similar purposes. The one thing I've found is that it's worth putting a decent mixer in front of it to get all the signals up to a line level. The on-board level adjustment in the MOTU appears to be all software controlled (think digital zoom on a camera) and it was difficult to get consistent signals from the various mics and direct boxes I used. I use the inserts on the Mackie to send the signal to the inputs on the MOTU.
The different in raw sound quality is noticable. Without "cleaning" the signals first, I rarely had enough of a signal to work with and the MOTU algortihms for adjusting the level just weren''t good enough for poor signals.
-Chris
I use a custom Web app I wrote in Python using IMAP to talk to our mail server. It's great for reading email. I also use Yahoo mail from the Web browser for my Yahoo account, but lately they've added a lot of Javascript features that use up the available memory and make the experience less enjoyable. Of course, this is all using the Web browser in the 2.x firmware. :(
We initially intended to do a homebrew version of the Mail app (the Web app was supposed to be a UI prototype), but upgraded our PSPs to 2.x before realizing the problems the upgrade caused. Of course, there was also the catch 22 with the browser - we needed 2.x for the browser to prototype but that made homebrews difficult.
Cleaning the mail app up and posting it online is on my short list of projects. It'll show up on my Web page sometime in the next few months (www.osl.iu.edu/~chemuell/downloads.php).
-Chris
I found this story about 18 hours after watching the Battlestar Galactica miniseries on a PSP on a plane. So, there's at least one person watching movies on the PSP. Of course, I ripped it to a memory stick and didn't watch it from UMD (in fact, I've never watched a UMD movie).
/. effect)). In fact, at the conference I just attended, there was "contention" for my laptop and I was stuck with just the PSP. It actually turned out to be adequate (though a chat client would have been nice). Text entry was a little annoying, but that's about it.
I'm really disappointed in Sony for their positioning of the PSP. It has so much more potential than as a vessel for movie sales. I take it with me whenever I travel and use it as my primary entertainment, Web, and email device (using a home-grown Web mail app with a UI designed specifically for the PSP - one of a few Web apps I've developed to deliver content in PSP-sized Web pages (sorry, no links as my server can't handle the
I really wish Sony would get on the ball with a suite of productivity/connectivity apps. They don't need to be complex, just enough to talk to IMAP/Exchange/iCal/Chat and get me the info I need one the road (I'm not in sales, so my needs are modest). Or even just offer an open development kit so those of us with fulfilling day jobs can hack together little PSP tools.
Productivity + Games + (non-UMD) Movies + Music in one small device is great for travelling...
*sigh*
-Chris
On the other hand, computer geeks reject Microsoft Windows because they don't know any different.
-ChrisThe best travel games I've found for the Gameboy Advance are the Advnace Wars series. I've spent entire trans-Pacific flights playing the longer campaigns. If only the airlines would build link cables into the seats for playing random passengers...
A close second lately has been Lumines on the PSP. Trying to get higher scores on the 60 second mode makes time fly (Did I really just play 80 rounds???).
-Chris
Just to reinforce the point that ActiveX/COM/.NET are important: there is no equivalent technology on Unix platforms that easily enables developers to share components across languages. One reason Windows is so successfull in the workplace is that it is trivial for a casual programmer to glue together many powerful components to create custom business applications.
The closest Unix comes is TCL and Python. These are the standard glue languages on Unix. But, using Python on Windows with COM really exposes how far behind Unix is. On Windows, you immediately have programatic access to almost every program installed on the computer. Its trivial to include an Excel spreadsheet in an application that loads data from a Web service, mixes it with a local Access database and uses VTK to render a fancy visualization. The same task on Unix is possible, but requires more effort and the UI controls are (for lack of a better term) clunkier (and that's all the user really cares about).
The Linux crowd really should put aside their predjudices and spend a few months writing Windows applications, just so they can understand what they're missing.
-Chris
I recently returned to school to work on a PhD after working in industry for seven years. Over the last two years, I've been involved in a number of software engineering projects with scientists and just recently helped hire a software engineer to "replace" me.
Here are some things I've learned:
1) If you're going for a degree, don't mix research and software engineering projects. You'll find yourself spending too much time as a software engineer and not enough developing your research skills. It's ok to have both types of projects, even as part of your official research, but keep the software projects separate from the pure research ones.
2) The only two deadlines that matter are grant deadlines and class deadlines. This is in contrast to working in industry, where there are often many deadlines with many people relying on you to meet them. Research and even academic software development works at a different pace. For the first year, I worked at an industry pace and nearly burned myself out. Then I realized that no one else was working at that pace and I could actually take my time and do things 'right'. This has greatly improved the quality of software I write and helped me hone my research skills by allowing myself the time to explore the problem completely.
3) Everyone is pretty much equal when it comes to intelligence. An earlier poster noted that post docs and other PhDs tend to be arrogant. This is true, but as far as I can tell it's really just a defense mechanism. They're often as itimidated by you (coming from industry) as you are of them. Ultimately, while I've found people's knowledge can vary widely, most everyone you'll work with has the same level of intelligence. And, once you get past the facades, academics are a lot of fun to work with. (and though they'll rarely admit it, they enjoy learning from people with industry experience)
4) The benefits are nice. At my school, the support employees earn competitive salaries ($50k/yr for junior programmers), get 6 weeks of vacation and good health coverage. Couple this with relaxed work schedules and it makes for a nice job.
5) You can't be a full time employee and student at the same time. For legal and practical reasons, pick one or the other and focus full time on it. You'll be saner in the long run. Everyone I know who consults on the side is overwhelmed with work and can't really enjoy the extra money they make. Of course, if you have a family to support, you may have to make some sacrifices (and I'm not talking about the kids).
Anyway, those are some observations. Good luck.
-rockmuelle
I think what the original poster was referring to with 'micro-RNA' was recent discoveries like siRNA and other forms of RNA that play important roles in the whole process but are never converted to protein.
My best understanding of siRNA's effect on genes (please correct me if I'm wrong) is that small RNA fragaments are trascribed from the DNA and actually bind to mRNA stands, inhibiting their expression. The coding regions for the siRNA strands are not the in the same location as the original gene that they help regulate, so it's difficult to find them (they were only discovered in the last 10 years) and difficult to know when they're affecting for the behaviour of a gene.
siRNA is only one example of the not-so-clean relationships between DNA/RNA/protein. Instead of the simple central dogma, it's turning out that there are many more complicated interactions at each level of abstraction (to use a CS term) and between levels.
So, while [genome sequencing|protein folding|etc] were all tought to be the grails at different times, they're all just turning out to be pieces of a larger puzzle.
I suspect that the real grail will turn out to be not one technology or algorithm (e.g. whole genome shotgun, protein folding) but a consistant model that ties them all together and gives biologists a solid theoretical framework to work with.
-Chris
Yeah, this is a few days late, but in case you haven't found it yet:
http://www.slimdevices.com/dev_third_party.html
The Slimdevices guys are really encouraging hacks and are hosting this list of links to them.
-Chris
This definately appears to be the case. I read the post and hoped that they were actaully streaming video to the squeezebox and using some clever server hack to modulate the video signal and send it out over one of the audio channels. This is not the case at all. They're just using the Squeezebox as the remote control for a PC connected to the TV.
While this isn't as exiciting, it's still a nifty hack. One of the great things about the Squeezebox is that its form factor and UI enable it to integreate seamlessly into an existing AV system. Not only does it look like an AV component, but it acts like one too. The UI is simple and it's easy to control with the remote control.
Other hacks let you use the Squeezebox to check weather and stock quotes. If your PC is already connected to your computer and you have a Squeezebox, this hack lets you control your audio and video using one remote and the simple display provided by the Squeezebox. It's looks like it's a natural way to combine two similar things (audio and video) under one UI, even though the data paths are completely separate.
So, even though it's not a streaming video hack, it's still a nifty hack.
(it's worth noting that I'm a Squeezebox owner and love the hacks that people have done for it - the few times I've had a cool idea for it, someone's already done it! It's a great community and it's great that Slim Devices has opened up the software for tinkering.)
-Chris
Yup, that's the one. We have one in our vis lab and you need a magnifiying glass to see the pixels (at least with my eyes).
:) Now if they just made it the size of a whiteboard...
Still not quite the resolution of printed paper (the T221 is around 200 DPI), but better than a pencil.
-Chris
M-x picture-mode
-Chris
I'll second this. I'm doing my second round of school (PhD after years of working) and am using a clipboard and paper instead of my notebook (computer) for notes. I had bought a nifty Vaio to take notes on and quickly abandoned it in favor of the tried and true pen(cil) and paper approach.
;) ).
Three other advantages are:
1) Paper notes don't disappear when your hard drive crashes
2) The resolution of paper and ink is still better than computer monitors (save for the IBM Bertha display)
3) Layout flexibility - it's much much much easier to just draw something on paper inlined with your notes than it is to do it in a word processor (though ASCII art in Emacs can be fast
Get a good notebook (or desktop) computer for other uses, but for taking notes, experience has taught me that you still can't beat a pen and paper.
-Chris
Let me offer a different perspective:
Back in '97 or so when Hotmail came out, I couldn't understand why anyone would use it. All you have to do is run a mail daemon somewhere or just use your email address from your ISP, right? Who needed Web-based email? Turns out, everyone did.
At the same time, I had a brainstorming session with some friends and we thought of things that we had used in college (early 90s) that hadn't made it out to the 'real' world yet. 'talk' was the one thing we all agreed on that hadn't made it big that we found indispensible. Of course, we also thought that all people needed to do was start using 'talk' or 'ntalk' or irc, so there wasn't really an opportunity there. Turns out there was an opportunity, almost as big as email: instant messaging. Same idea, different implementation. Bummer.
The point is, while some things seem obvious and even trivial for the geek, they are often completely inaccessible to the average user. This is not a fault of the user or the technology industry, it's just the way things are.
I read the Wired article in print a few weeks ago and viewed it from this perspective. I thought it was great and full of good ideas.
-Chris
coulnd't resist.
Someone mod the parent up a bit, please!
:) ) on just about every topic related to Windows development.
Having developed extensively for *nix and Windows, I have found MSDN and Knowledge Base to be extremely thorough and useful. Both draw from the extensive collection of articles written by the MS devloper community to provide clear answers and how-tos (lower-case
I know this thread is a pat on the back for the HOWTO's, but it shouldn't be used to spread FUD about MS's alternative.
-Chris
Scientific and financial computing, especially modelling and simulation, are where parallel computers can make a difference.
Many of the approaches to these problems take the form of a grid of elements that have local and possibly non-local interactions with each other. Each processor gets a subset of the points to work with and has to communicate with the neighboring processor's memory space to get information about neighboring points.
In a cluster, handling the points at the edges (or any non-local effects) requires a network and possibly disk request. Compared to local memory, this is incredibly slow and can temporarily starve the processor.
Big iron parallel systems address this by giving more processors access to the same memory and other shared resources, avoiding the costly network requests.
Of course, the current super computers (ASCII *, etc) are all clusters, just with incredibly fast network connections.
-Chris
1. Calling Marvel's Silver Age comics "the most famous run of comic books in history" is a highly subjective and arguably mistaken statement. More famous than the early years of DC, with Batman and Superman? I don't think so.
This reminds me of my comic book days in the late 80s and early 90s when there were Marvel readers (X-Men, Spider Man), DC readers (Frank Miller, Sandman), and the indies (Cerebus, early Groo, etc). Each readership had a very myopic view of the world and was convinced their publisher was the most important.
For Marvel people, the Silver Age was when comics came of age. DC people pointed out that Superman and Batmen essentially created the industry and the indies suggested that everything up until then was crap (with the odd exception of X-Men, which everyone seemed to like). It was silly then and is silly now. A real, unbiased history that covers all publishers and ages would be nice. Does one exist?
As for myself, I'm a Barks man. Nothing beats his early Four Color epics.
-Chris
Someone mod the parent up!!
From a geeky, awe of nature, just sheer beauty perspective, nothing beats Yosemite. Sure, it's crowded, but with a backpack, the crowds are easy to avoid.
Close second: The Grand Canyon. An hour is all you'll need, but it will be one of the more awe inspiring hours of your life.
If you really need a geek perspective before moding the parent up, think geology. These are two of the most amazing examples of geology on the planet.
-Chris
I should've qualified my last post a bit by stating that the data visualization I've been involved with is primarily scientific visualization. I have also been developing Web based vis apps since 1997, so I understand the challenges well. In this domain, the sub-sampled data sets are still large and the cost of resampling can be high. Thus, it is important to get as much data to the client as possible to perform meaningful interactive analysis.
...That's a classic complaint. Features I don't use are bloat. We need more features that I will use...
It is also often the case that when the user selects client side data, that data needs to be processed before it is re-rendered, a task not well suited for JavaScript and DOM-based data structures. Putting all the processing on the server tends to defeat real interactivity - 1 to 10 second delays are not acceptable when the user is trying to explore the data (note that this is a problem with Web apps in general, not just SVG apps).
smallpaul:
I never said I don't use the features. My complaint with SVG is that it's growing too fast for developers to keep up with it. It's been tough enough to get a working SVG viewer that supports the first few versions, let alone one that supports the most current. With no one working on the same version and the language developers adding new features, there hasn't really been time for anyone to figure out what should be in the language and what should be extensions (though the new extensions framework holds promise for helping out here). It's quickly becoming a jack-of-all-trades, master-of-none.
The is a real need for a consise vector graphics language, as both a Flash replacement and a tool for data graphics. I'm still holding out hope that SVG will mature into this language.
-Chris
SVG has a long way to go before it will be suitable for data visualization. Most real world visualizations are based on large datasets and require a certain degree of interactivity. Both of these are possible using SVG. However, coding up an interactive application using JavaScript and the DOM model favored by the SVG designers is a non-trivial task.
A typical data set may contain 10,000 or more elements (e.g. financial analysis, temperature/forcast data, usage stats for a medium size web site, marketing data for a product line). Immediately, this requires a DOM tree with at least that many nodes. Given that each node requires a certain amout of meta-data and a containment heirarchy, the amount of data that needs to be transferred between the client/server, parsed, and managed in the browser grows quickly.
Ignoring the physical challeges of using DOM, there is also an abstraction challenge: Not all data fits nicely into the tree/scene-graph paradigm embraced by SVG. Of course, data can be transformed to use this model, but manipulating the data will be much more challenging.
Assuming a suitable DOM representation of the data exists, the next challenge is developing the JavaScript to allow the user to explore and manipulate the data. With no real package support and no built-in way to manage a large code base, JavaScript is not the ideal language for developing reusable vis code.
Before data visualization becomes commonplace in SVG browsers, another abstraction will need to be built on SVG that addresses the specific needs of the data vis community. This could be in the form of libraries that abstract the SVG frameworks with data vis APIs or another XML dialect that can be transformed into SVG.
I'm holding out hope that the SVG community will slow down on the feature creep and architecture bloat and focus on developing applications with the currect standard. Only by stepping back and trying to use the current system will the architects of SVG know what's missing and what needs improvement.
-Chris
I work for a biotech developing their informatics syste, and have been heavily exposed to the challenges of working with chemical and biological data. And, I will be starting work on a PhD in CS focusing on these areas in August.
A quick note, I use the more general term 'life sciences' to denote the field that this work affects. While chem, bio and medicine are traditionally seperate disciplines, the computational problems are similar and shouldn't be forced into the old categories.
The biggest challenge currently facing both people attempting to solve problems in the life sciences using computers and those trying to implement computers using organic materials is the lack of mathematical and computational models to describe these systems.
Step back 50 years to the early days of computing. Computers were designed and envisioned as equation solvers and theorom provers (gross simplification, but bear with me). The physical sciences naturally adapted to computers since most of their theory is written using the language of mathematics. These fields helped push high-performance computing to where it is today and in doing so, molded the field to solve math-based problems.
During the same time period, the life sciences were starting to understand DNA. With a strong tradition of wet-lab and notebook based work, computers were essentially ignored. This changed somewhat with data aquizition systems in the 70s and 80s, but to this day, most analysis is still done on paper or in generic spreadsheets, using printouts from data systems (I see this every day).
On the modelling side, accurate mathematical models for even the simplest chemical and biological processes do not exist. While there's an obvious mapping of DNA to bits, no one has been able to do anything useful other than similarity searchers (which are rooted in math). The 'obvious' solutions to most problems (eg, protien folding) are generally NP-Hard and simplifications tend to yeild poor results that are not consistent with nature even for the simplest datasets.
Thus, the challenge in working with life sciences problems lies in the lack of a mathematical and computational system that can be used to explore the problems. Current research into linked systems (networks) and agent-based systems appear to be promising areas, but they quickly run into the same computational limitations of modelling life sciences problems - ie, they grow too big too fast.
Note that this discussion has left out the data analysis and processing problem (traditional bioinformatics), but it's worth mentioning that many of the same challenges exist. With no theoretical foundation for the data, it is hard to come up with a meaningful interpretation.
So, it appears that what is needed is not more articulation of current mathematical and computational models, but rather a different theoretical framework to work with. As mentioned, networks and agents brush this surface as haves chaos, cellular automata, complexity, neural nets, and most other 'fun' ideas of the last 20 years. Wolfram attempted to and has probably failed at providing a new framework to work within, but others are still looking and his ideas will hopefully lead to other insights towards this end.
The key here is that it will probably not be based on predicate logic and only implementable on Turing machines in ways that make it non-computable. So, a completely new system of logic will be required and a new model for computers.
Once this is in place, then life sciences problems will be accessible computationally. In the meantime, there are still lots of math-based problems that our current models will help sovle.
-Chris