So, I was in a similar situation with a mobile app recently. There weresome novel components and some components that most likely infringed on existing patents.
To help put my mind at ease, I spent some time with (and money on) a lawyer. It was worth every cent. We talked about different components that could be patented, he did a prior art search, and we discussed how to handle any claims brought up by holders of related patents. At every step, I gained a much better insight into the realities of patent law and dispelled many myths and prejudices gained over the years from slashdot. Based on the results of this interaction, I decided not to pursue a patent at this point and I feel much more comfortable about my app's relationship to existing patents.
If you choose to do it, make sure to go in prepared:
1) Have a good written description (with screenshots) of your application prepared that highlights the novel components and those parts that may be covered by existing patents. 2) Have a list of similar apps 3) Have a timeline of any public presentations/publications you've made of your app. 4) Understand your business model and have at least a 2 page executive summary of your business plan prepared
(1) and (2) will save you time/money with the lawyer. They'll need this information to help with patent searchers and to develop claims. The more work you've done ahead of time, the less you'll pay a lawyer to do. Don't worry about trying to write claims, just get a good english description of things. (3) matters for patents. In the US, you have a year after publication/release to file. Overseas, you can't file after publication/release.
(4) will help you decide how much money to spend on the process. If youre (realistic) business model only shows you generating $10k over the lifetime of your product, it's probably not worth spending any time with a laywer. The amount of revenues you project will help determine how much IP protection you're willing to pursue (i.e., pay for:) ). Just for some numbers, a patent will run you $10-20k up to the initial filing. The early search, however, will cost less than $5k (in my case around $1500). If you're serious about the business, the cost of the search shouldn't bother you.
Anyway, I hope this is a more useful "hire a lawyer post"...
It is a big deal. The two most important things concepts were going to do was make generic programming in C++ (1) explicit and (2) accessible.
Currently, generic programming in C++ is supported through a number of template meta-programming patterns and practices, most of which exist as Boost tribal knowledge - hail King Dave!* It is implicit in many library designs, but there is nothing enforcing it at the language level. If you're not familiar with the concepts of generic programming (pun intended), it's easy to mistake what's going on in the standard libraries as something else. This is especially true if your primary use of the STL is to have polymorphic container classes - you might just design a generic extension to another language that completely misses the point of generic programming (see Java Generics).
At a more fundamental level, a lot of the power in generic programming comes from the specializations that are possible when you meet type requirements. Right now, there is no way, outside the documentation, to state requirements and possible specializations. Making this explicit in the language makes it clear to the library user what the requirements are and what specializations are available.
This leads into the accessibility problem. Generic Programming using template meta-programming is difficult. To use it, you have to understand both the template system and generic programming. The former is defined in the standard, but the latter, as mentioned above, is tribal knowledge. By making generic programming explicit in the language, it immediately becomes accessible to a large number of developers who didn't have the time, patience, or fortitude (dealing with the Boost mailing list requires a large supply of this) to become proficient with template-based generic programming.
As an analogy: consider object-oriented programming in C. Prior to (and even after) C++, lots of OO code was been developed in C. But, each object system was different and based on local best-practices. C++ (and Objective-C) took those practices and codified them into a language extension. As soon as that occurred, one method for OO was standardized. Developers no longer had to implement their own object systems and adhere to documented (but not language enforced) policies. And, with a standard set of rules around this flavor of OO, many other developers felt comfortable jumping in the the fray.
Concepts in C++ should have had the same effect for Generic Programming in C++ that C++ had for Object Oriented Programming in C. The should have democratized generic programming and brought forth a renaissance in C++ library design. Instead, petty politics killed the most exciting change to C-like languages in years.
-Chris
*(Dave - I mean that in the nicest sense... you've done a great job with Boost (oh, we need to jam again, too)).
(disclaimer: I develop GPS applications for mobile devices, including the iPhone)
The chipsets in mobile phones can't compete with those in standalone devices. When you're sharing power between multiple radios (wifi, bluetooth, GPS, 2/3/4/nG, etc), there's just not enough power available for a running a GPS that can compete with a good standalone unit. There's also the physical space issue: the GPS needs a decent antenna that has to share space with all the other components in a cell phone.
For walking directions, this isn't a huge deal. But, I wouldn't trust my iPhone GPS for realtime directions when I'm traveling 50 miles per hour. The iPhone's GPS can't deliver updates fast enough to make quick decisions. Sure, it will sometimes, but all it takes is one delayed direction in 10 million to cause an accident. I could see it used on highways where the next turn is a few miles off, but for city driving where you might make a few quick turns, I can't see it working very well without some assistive technology.
The apps we develop require a high degree of precision. We've had to develop technology to augment the GPS units in the mobile devices to provide this precision. I'm sure other companies have done this too, but it's not cheap to do and the optimizations tend to exploit specific features of the application (in other words, the tricks used for one application may not be practical for another).
The parent also points out the maps issue: standalone GPS units don't need a connection to the internet to display maps. Most mobile apps due, simply because there isn't enough storage space on the devices to store all the map data users are accustomed to having at their fingertips (elevation, traffic, satellite, home prices, etc). The lack of a connection also makes hiking/biking/off-roading/boating apps useless on mobile devices - most of those activities take place where there's no network coverage.
"Anybody out there know a good emulator for teaching assembly programming?"
CorePy (www.corepy.org), while not an emulator, is probably the easiest way to learn assembly. It's a complete environment for assembly-level programming using Python and supports all the major platforms (x86[_64]/SSE, PPC/VMX, Cell SPU, ATI GPUs).
Instead of using inline assembly, CorePy represents all assembly instructions as Python objects, leading to a very natural syntax and also enabling some really interesting methods for generating assembly code using Python as the meta-programming language.
"Of course, that won't happen because IT professionals never make mistakes."
It's not just IT professionals. It's bioinformatics in general. Most of the code at the heart of these pipelines was developed by grad students to generate publications. The code is not production quality. The code is always poorly commented. Scientific validation is very ad-hoc - there are no generally accepted methods for validating algorithms that operate on genomic data. There's a culture in bioinformatics (and to some extent, scientific computing in general) of ignoring software quality when the code generates the results that were "expected".
Unfortunately, once something is published, biologists tend to trust it. This generally works for wet-lab protocols, where the reviewers are familiar with the experimental design and analysis. But, bioinformatics papers are often reviewed by the same people, who are completely unqualified to review software papers (most computer scientists are, too, but that's another post for another day).
But, don't believe me, see for yourself. These programs are forming the foundation for the next generation of personalized genomics applications:
Are forks really a fact of life for healthy open source projects?
Most open source tools I use on a regular basis have never been (successfully) forked. More importantly, none of the other members in the LAMP stack have undergone a forking of the scale that MySQL is about go through. Sure, there are multiple 'L' distributions, but there isn't a healthy eco-system of production forks at the kernel level.
You will never look at statistics the same way again after reading this book. Great story about how different measures if intelligence (e.g., IQ) were developed to prove prejudices rather than seek objectivity.
If you love PPC assembler, check out CorePy (www.corepy.org). Full support for the PPC/VMX ISAs using Python as the "assembler".
We're doing our best with CorePy to make assembly programming fun and accessible to a new generation of coders. There's also support for the Cell SPU ISA (e.g., Playstation 3) and x86/SSE with support for AMD/ATI's CAL GPU ISA coming soon.
1990s... Apple stops using 5 1/4" floppies in favor of 3 1/2" disks... Apple standardizes on Firewire/USB, obsoletes parallel and RS-232 ports... Apple stops using floppy disk drives all together 2000s... Apple introduces LCD iMac, no longer sells CRTs... Apple locks the battery in the MacBook Air - replacable batteries obsolete! (ugh)... Apple breaks Perl in OS X, the world moves away from write-only languages
Agreed that I can just not use the software. But, by giving away a free version of an incredibly expensive to develop piece of software, Google has guaranteed that there will be no competition in the virtual globe market. So, I have no option but to use Google Earth if I want to use virtual globe. (and, yes, I am aware of MS Virtual Eart, NASAs WorldWind, and the others.. they cannot compete with Google Earth anymore... Kinda like MS and Netscape with free browsers...)
For updates on Macs... I use and pay for OS X in part because of the nice auto-update feature. I expect my OS vendor to keep critical software up to date. But, I can also disable the feature if I want. I do not expect or want forced updates from any other piece of software on my computer, free or purchased.
Next to the Mythical Man Month, this is a must read for anyone working on software with more than one person. It covers all aspects the human side of software development and includes a wealth of information not only how how to manage software projects but also what environments work best for software development.
It's based mostly on research from the 1970s, but is still surprisingly relevant. The latest edition updates some of the core lessons for the internet age (e.g., substitute phone calls for email messages, and you get a similar break in 'flow').
> (so how are we supposed to go about iterations, theorists ?)
Like you, I've written a number of template engines because I didn't like the limitations of existing ones (granted, this was in the mid to late 90s, so there weren't many to choose from).
After including iterators and conditionals in two different templating engines, I decided to try to design one without these programming constructs. I had seen too many UI designers find 'clever' uses for loops and conditionals and I wanted to see if it was possible to push them just out of their reach. I was also starting to see templating engines come out that placed unnecessary limitations on developers and wanted to see if I could strike a happy medium (fully enable good developers, properly contain UI people who thought they were developers).
The solution was a combination of JSP tags and XSLT. The attributes on the tags were designed to give the UI developers control over 'stateful' list generation (e.g., generate the first 10 items, generate items 5-10, etc...). The tags themselves generated an XML stream that the UI designer transformed into markup for the target platform (this app targeted desktop browsers, Palm Pilots, and old-fasioned WML-enabled phones). While XSLT does give the UI designer basic conditionals and iteration, there wasn't enough information available in the XML stream to do much harm and most UI designers could only handle basic transforms.
The key to making this work was careful design of the tag libraries that handled the program logic. In many cases, the tag libraries were actually implemented using JSP, with JSP used as a programming tool to generate XML rather than UI tool to generate UIs.
I'm sure there are some important details that have been lost to time, but in the end, the system met the goal of separating templating and control without sacrificing development flexibility (and, most importantly, without annoying the developers or UI designers).
So, it's definitely possible to build a full-featured templating engine that limits iteration and other programming interfaces. (and trust me, I had my doubts before designing the system)
Not on GPUs. The asm for any particular GPU line is not published and (according to sources at GPU companies) changes fairly often. Drivers that expose the GPU via OpenGL, DirectX, CUDA, etc. hide the programmer from this fact and allow the manufacturers to change the underlying hardware without changing the programmatic interface. These higher level APIs _are_ the assembly language for GPUs.
As an aside, this is the main reason CorePy (an Python-based assembly system I develop) does not support GPUs.
I'm sure the hard core people use assembly on general purpose processors, but I can guarantee they don't use assembly on GPUs.*
-Chris
*unless, of course, they're reverse engineering the GPUs and developing their own run-time system to execute the assembly language they've reverse engineered and doing this for every new release of a GPU. That's definitely hard-core, but usually good hard-core people are smart enough to know when they've gone overboard, hard-core young-uns excluded, of course.
There were some good points raised in the replies. I was definitely referring to Ivory Tower-type PhD students. Their job is research, not development. If they want to do development, they really need to rethink why they are in a PhD program. Any development they do should be to further _their_ research, not someone else's. This is a distinction often lost on people who haven't experienced graduate school. The research aspects of software engineering and computer science are very different than the development aspects. It took me about a year and a half into a PhD program (after years of working in industry) to realize this. Unfortunately, I still haven't found a way to easily communicate it to people who haven't been on both sides. Every now and then, there is value in a software-oriented thesis, but those that can become usable software while still making valuable research contributions are few and far between (projects like the Boost Graph Library fall in this category). And, those are usually personal, not collaborative projects.
CS/Informatics Masters students are an interesting case, especially at schools where a Masters Thesis is an extended software project. In this case, it's OK to partner with a student as long as you: 1) make sure the project you're doing is within their abilities and 2) make sure the time line for the project aligns with the the student's program. This is valuable experience for the student and their colleagues.
Physics, biomed engineering, bioinformatics, etc students are little trickier. In the case of Masters students with thesis projects, the comment above still holds. But, in these cases, it's important for everyone involved to make sure the best interests of the student are respected. These students are often lacking the software foundations that CS students have (not that CS students have much more) and require the proper mentoring from a good software developer in order to develop good habits. I've seen firsthand the effects of letting students learn to program without a good mentor and it's not pretty. The real risk here is that the software will not be scientifically valid - it may run and appear to produce good results, but without the proper oversight, there's no way to be sure if the results are valid. (again, this is true of CS students too, but the risk is higher when there are no experienced software people involved).
The most important point in this discussion, however, is this: Graduate school is for furthering education and, in a PhD track, developing research skills. Graduate school is not the place to do a software apprenticeship (that magical 0-3 years experience that gets you into the more interesting jobs). In most cases, the student is losing money by being in grad school and taking advantage of them as a source of cheap labor is not fair to them or the discipline of software engineering. Unfortunately, students rarely understand this and a number of professors actively exploit it. Of course, money isn't everything and there is something to be said for working on fun projects, but just make sure everyone's best interests are taken into consideration when entering into an academic development partnership.
Developing software in a research environment is challenging. There are a number of constraints and conflicting interests that make it difficult for researchers unfamiliar with software to be truly successful. To make matters worse, the relationship between academics and professional software developers is almost non-existent, in large part simply because the research community has limited funds available for software development.
I've worked with a number of research labs to help bridge this gap and have developed a basic set of guidelines for developing software in research environments. In the end, the most important thing to do is draw a clear line between research tasks and development tasks. Understand what is in your area of expertise (research) and what is best handled by software engineers and other professionals. Then, depending on your resources, either hire a full time development team, a part-time consultant, or work with your university's IT staff to find local resources (many universities provide software development services). The place not to look is in the CS department: those students are there to do research, not write software.
I've put together a presentation that outlines a number of the challenges and how to address them. This presentation has evolved over the last 5 years based on a few ongoing academic research projects that have applied the ideas in it. Most of the ideas are standard practice in industry, but applying them to academic projects can be trick.
CS grad students are in their program to do research, not develop software for other departments. Their time should be spent working towards their thesis. There is no research value in applying software engineering practices to develop an application for a researcher in another field. I know some schools allow theses along the lines of "A Software Framework for Cool Science Problem X", but these types of projects only shortchange the CS student. The projects are simply software engineering and should be handled by software engineers, not potential researchers.
There's also the problem that most CS grad students have never developed large scale software and are essentially in the "0-3 years experience" range. While they are usually very bright, they are not skilled practitioners yet. The code they develop will have all the same problems that plague young developer's code: little reuse, lots of reinvention, tendency towards trendy solutions (Oh! Let's do the whole thing as an Eclipse Plug-in/OO Framework/Scheme Interpreter/etc), and overly clever solutions. If the research wants to learn software engineering, their time is much better spent earning decent wages at a real software company with people who can provide proper mentoring.
Finally, there is the conflict of interest. A researcher's main goal is to perform research and publish papers. Software does not count as a publication. Thus, the software will be developed up to the point where there is something to publish and not much beyond. And, once the student completes their degree, they are off to greener pastures and support will quickly dry up.
So please: Stop using CS grad students as software developers!!! It hurts everyone!!!
First off, I really appreciate the well-thought out comments to my original post. I was expecting some flame-worthy comments and am pleasantly surprised.
Now, to make this a proper/. thread and go completely off-topic...
I want to follow-up briefly on the NIOS idea, as it's one I've bandied about in academic circles for addressing the challenges facing researchers who need software for data management or simulation. The standard approach is to find a research angle and have a grad student develop the application in exchange for a degree. However, most disciplines are reaching the point where the requirements carry no legitimate research value or are simply beyond the skills of students. "A [OO|XML|Java|Perl|Forth] Framework for Baconian Dymanics" can only be published so many times before the reviewers catch on. And, it's not really fair for a student who should be developing research skills to spend their time writing boiler-plate code.
Some labs are able to secure NSF or NIH funding for software development. But, once they have the money, it's rarely spent on professional developers. Instead, it goes to the lowest bidder (or a colleague's kid who learned HTML in high school) and the quality of the software takes a big hit. And, most scientific PI's have difficulty effectively managing software projects.
It seems that the NIH/NSF could invest in a National Software Institute that provides developers for academic projects. The trick would be not to become a typical consulting shop and instead develop long term relationships with the labs while building out shared frameworks/toolchains/(pick your favorite abstraction technique) that can be used across similar projects. It would also be important to hire developers who were interested in science and would take the time to understand the domain they're supporting. And, it would be essential to develop reliable QA and validation practices to ensure that the science they're supporting is reproducible (something that most people I've worked with agree is lacking in most scientific software).
Anyway, some of the foundational ideas are worked out in a talk I put together and have given to a number of different labs. It's more focused on how to get individual labs implementing good software development practices, but I've always wanted to see the core ideas scale to a larger service organization. If anyone's curious, the slides are at:
This raises an interesting point that I'd like to see/.ers discuss:
Without the charity of well-to-do geeks or companies that fund open source development from profitable product lines, can Open Source succeed at the enterprise level?
This thread is a good example of the first case. Sun/Open Office, the Google/Mozilla "relationship", IBM, et al./Eclipse are examples of the second as is the general practice of different companies employing Linus, Guido and a few other key people to keep Linux/Python/etc going.
Without the strong investment from those with deep pockets, can Open Source software progress at the rate needed to remain viable in the enterprise? What happens when the product lines funding those projects start losing money?
If you respond with counter-examples, make sure you do a proper accounting of who is really doing the development work on the project. Is it people in their spare time or is it paid workers being funded by the revenues from other projects? And, of course, focus on Open Source software that is being pushed and is _viable_ for enterprise use - hobbiest level software and boutique libraries will always have volunteers available.
Of course there will - there are plenty of embedded device programmers who are well acquainted with the bare iron, and having to code economically. There are still a lot of people around today who make a living from writing 8 bit software on systems with 2K of RAM.
Also, keep in mind that for data-intensive, I/O-bound HPC applications (think next-generation genome sequencing and "personalized genomics"), efficient use of large amounts RAM is very important. In fact, many of these applications are bound by the cost of RAM - while they could benefit from 256 GB, the cost is currently too high (I know: I just tried to justify purchasing such a system). Good programming is very much a requirement for these applications (though the practitioners in these fields are only starting to realize this).
The Cray CX1 is an interesting entrant into the market for these types of applications. The only major drawback is the limited amount of RAM per node. They should support at least 64 GB and ideally up to 256 GB (I know the summary says they support 64 GB, but the order page only allows up to 32 GB/node). Oh, and I want 20 TB of fast disk along with 8 compute nodes, not in place of 6 of those compute nodes.:)
To all the people wondering where the ad-blocker in Chrome is, you should read Google's annual report.
From the second paragraph of the actual report (not the founder's letter):
We generate revenue primarily by delivering relevant, cost-effective online advertising. Businesses use our AdWords program to promote their products and services with targeted advertising. In addition, the thousands of third-party web sites that comprise the Google Network use our AdSense program to deliver relevant ads that generate revenue and enhance the user experience.
Now, please explain why Google would ever want to enable ad-blocking or even make it easy for a third party to do so. If Chrome had a large market share and ad-blocking was enabled, Google would be toast.
My point has nothing to do with government limits or anything like that.
What I mean is that by Google using this as their primary data source and with 50 cm being "good-enough" for a lot of applications, there will be less incentive to invest the better aerial data. It's just the simple fact that once the market is flooded with 50 cm data, most people won't know that there are better resolutions available and most consumer applications will be built around 50 cm as the standard.
If Google used 40 cm or 6 inch data, the same would be true. I just worry that we'll be stuck with 50 cm data for the foreseeable future because of this. (and I'm greedy and want the world at 6 inches!)
Well, it's not really news. If you understand the different data sources, it should come as no surprise that these images are not as good as the high-resolution aerial photos and as good as good satellite photos (think of the before/after tsunami photos)
Good aerial photos have a pixel resolution of 6 inches. Decent ones are 12 inches. GeoEye-1's resolution is 50 cm, or about 19 inches. 19 inches is good for working with large objects, but not useful for fine-grained measurements. (it will be fine for 99.9% of the apps Googlers develop)
For a good example of 6 and 12 inch data, look at the state of Indiana (in the US) in Google Earth. In 2005/6, Indiana re-imaged the entire state with aerial photos. The whole state is at least 12 inches and all metro areas are 6 inches.
I'll be really excited when we can get continually updated 6 inch data... My only concern is that with Google's dominance, we'll be stalled at 19 inches for a long time and people will start to think that's the best we can do.
Slashdot Mirror
So, I was in a similar situation with a mobile app recently. There weresome novel components and some components that most likely infringed on existing patents.
To help put my mind at ease, I spent some time with (and money on) a lawyer. It was worth every cent. We talked about different components that could be patented, he did a prior art search, and we discussed how to handle any claims brought up by holders of related patents. At every step, I gained a much better insight into the realities of patent law and dispelled many myths and prejudices gained over the years from slashdot. Based on the results of this interaction, I decided not to pursue a patent at this point and I feel much more comfortable about my app's relationship to existing patents.
If you choose to do it, make sure to go in prepared:
1) Have a good written description (with screenshots) of your application prepared that highlights the novel components and those parts that may be covered by existing patents.
2) Have a list of similar apps
3) Have a timeline of any public presentations/publications you've made of your app.
4) Understand your business model and have at least a 2 page executive summary of your business plan prepared
(1) and (2) will save you time/money with the lawyer. They'll need this information to help with patent searchers and to develop claims. The more work you've done ahead of time, the less you'll pay a lawyer to do. Don't worry about trying to write claims, just get a good english description of things. (3) matters for patents. In the US, you have a year after publication/release to file. Overseas, you can't file after publication/release.
(4) will help you decide how much money to spend on the process. If youre (realistic) business model only shows you generating $10k over the lifetime of your product, it's probably not worth spending any time with a laywer. The amount of revenues you project will help determine how much IP protection you're willing to pursue (i.e., pay for :) ). Just for some numbers, a patent will run you $10-20k up to the initial filing. The early search, however, will cost less than $5k (in my case around $1500). If you're serious about the business, the cost of the search shouldn't bother you.
Anyway, I hope this is a more useful "hire a lawyer post"...
-Chris
It is a big deal. The two most important things concepts were going to do was make generic programming in C++ (1) explicit and (2) accessible.
Currently, generic programming in C++ is supported through a number of template meta-programming patterns and practices, most of which exist as Boost tribal knowledge - hail King Dave!* It is implicit in many library designs, but there is nothing enforcing it at the language level. If you're not familiar with the concepts of generic programming (pun intended), it's easy to mistake what's going on in the standard libraries as something else. This is especially true if your primary use of the STL is to have polymorphic container classes - you might just design a generic extension to another language that completely misses the point of generic programming (see Java Generics).
At a more fundamental level, a lot of the power in generic programming comes from the specializations that are possible when you meet type requirements. Right now, there is no way, outside the documentation, to state requirements and possible specializations. Making this explicit in the language makes it clear to the library user what the requirements are and what specializations are available.
This leads into the accessibility problem. Generic Programming using template meta-programming is difficult. To use it, you have to understand both the template system and generic programming. The former is defined in the standard, but the latter, as mentioned above, is tribal knowledge. By making generic programming explicit in the language, it immediately becomes accessible to a large number of developers who didn't have the time, patience, or fortitude (dealing with the Boost mailing list requires a large supply of this) to become proficient with template-based generic programming.
As an analogy: consider object-oriented programming in C. Prior to (and even after) C++, lots of OO code was been developed in C. But, each object system was different and based on local best-practices. C++ (and Objective-C) took those practices and codified them into a language extension. As soon as that occurred, one method for OO was standardized. Developers no longer had to implement their own object systems and adhere to documented (but not language enforced) policies. And, with a standard set of rules around this flavor of OO, many other developers felt comfortable jumping in the the fray.
Concepts in C++ should have had the same effect for Generic Programming in C++ that C++ had for Object Oriented Programming in C. The should have democratized generic programming and brought forth a renaissance in C++ library design. Instead, petty politics killed the most exciting change to C-like languages in years.
-Chris
*(Dave - I mean that in the nicest sense... you've done a great job with Boost (oh, we need to jam again, too)).
"Much like Sun doesn't get an ovation or money when a successful Java project is deployed, I fail to see how this is different."
Sun's engineers were paid for their work on Java. That's the difference.
Recognition is great and all, but it doesn't put food on the table or pay for the computers used to develop the software.
-Chris
(disclaimer: I develop GPS applications for mobile devices, including the iPhone)
The chipsets in mobile phones can't compete with those in standalone devices. When you're sharing power between multiple radios (wifi, bluetooth, GPS, 2/3/4/nG, etc), there's just not enough power available for a running a GPS that can compete with a good standalone unit. There's also the physical space issue: the GPS needs a decent antenna that has to share space with all the other components in a cell phone.
For walking directions, this isn't a huge deal. But, I wouldn't trust my iPhone GPS for realtime directions when I'm traveling 50 miles per hour. The iPhone's GPS can't deliver updates fast enough to make quick decisions. Sure, it will sometimes, but all it takes is one delayed direction in 10 million to cause an accident. I could see it used on highways where the next turn is a few miles off, but for city driving where you might make a few quick turns, I can't see it working very well without some assistive technology.
The apps we develop require a high degree of precision. We've had to develop technology to augment the GPS units in the mobile devices to provide this precision. I'm sure other companies have done this too, but it's not cheap to do and the optimizations tend to exploit specific features of the application (in other words, the tricks used for one application may not be practical for another).
The parent also points out the maps issue: standalone GPS units don't need a connection to the internet to display maps. Most mobile apps due, simply because there isn't enough storage space on the devices to store all the map data users are accustomed to having at their fingertips (elevation, traffic, satellite, home prices, etc). The lack of a connection also makes hiking/biking/off-roading/boating apps useless on mobile devices - most of those activities take place where there's no network coverage.
-Chris
"Anybody out there know a good emulator for teaching assembly programming?"
CorePy (www.corepy.org), while not an emulator, is probably the easiest way to learn assembly. It's a complete environment for assembly-level programming using Python and supports all the major platforms (x86[_64]/SSE, PPC/VMX, Cell SPU, ATI GPUs).
Instead of using inline assembly, CorePy represents all assembly instructions as Python objects, leading to a very natural syntax and also enabling some really interesting methods for generating assembly code using Python as the meta-programming language.
Check it out! :)
-Chris
"Of course, that won't happen because IT professionals never make mistakes."
It's not just IT professionals. It's bioinformatics in general. Most of the code at the heart of these pipelines was developed by grad students to generate publications. The code is not production quality. The code is always poorly commented. Scientific validation is very ad-hoc - there are no generally accepted methods for validating algorithms that operate on genomic data. There's a culture in bioinformatics (and to some extent, scientific computing in general) of ignoring software quality when the code generates the results that were "expected".
Unfortunately, once something is published, biologists tend to trust it. This generally works for wet-lab protocols, where the reviewers are familiar with the experimental design and analysis. But, bioinformatics papers are often reviewed by the same people, who are completely unqualified to review software papers (most computer scientists are, too, but that's another post for another day).
But, don't believe me, see for yourself. These programs are forming the foundation for the next generation of personalized genomics applications:
http://www.oxfordjournals.org/our_journals/bioinformatics/nextgenerationsequencing.html
Download the software developed for any those papers. Browse the code. Be afraid.
-Chris
Are forks really a fact of life for healthy open source projects?
Most open source tools I use on a regular basis have never been (successfully) forked. More importantly, none of the other members in the LAMP stack have undergone a forking of the scale that MySQL is about go through. Sure, there are multiple 'L' distributions, but there isn't a healthy eco-system of production forks at the kernel level.
-Chris
You will never look at statistics the same way again after reading this book. Great story about how different measures if intelligence (e.g., IQ) were developed to prove prejudices rather than seek objectivity.
-Chris
Shameless plug:
If you love PPC assembler, check out CorePy (www.corepy.org). Full support for the PPC/VMX ISAs using Python as the "assembler".
We're doing our best with CorePy to make assembly programming fun and accessible to a new generation of coders. There's also support for the Cell SPU ISA (e.g., Playstation 3) and x86/SSE with support for AMD/ATI's CAL GPU ISA coming soon.
-Chris
""World: Yeah, you know what? You only had one good idea"
It's true. RMS has only had one good idea. That the end user should have the freedom to completely control their computing experience."
It's true that RMS had only one good idea. It's called Emacs. :)
-Chris
1990s ... Apple stops using 5 1/4" floppies in favor of 3 1/2" disks ... Apple standardizes on Firewire/USB, obsoletes parallel and RS-232 ports ... Apple stops using floppy disk drives all together ... Apple introduces LCD iMac, no longer sells CRTs ... Apple locks the battery in the MacBook Air - replacable batteries obsolete! (ugh) ... Apple breaks Perl in OS X, the world moves away from write-only languages
2000s
*ducks*
-Chris
Agreed that I can just not use the software. But, by giving away a free version of an incredibly expensive to develop piece of software, Google has guaranteed that there will be no competition in the virtual globe market. So, I have no option but to use Google Earth if I want to use virtual globe. (and, yes, I am aware of MS Virtual Eart, NASAs WorldWind, and the others.. they cannot compete with Google Earth anymore... Kinda like MS and Netscape with free browsers...)
For updates on Macs... I use and pay for OS X in part because of the nice auto-update feature. I expect my OS vendor to keep critical software up to date. But, I can also disable the feature if I want. I do not expect or want forced updates from any other piece of software on my computer, free or purchased.
-Chris
Next to the Mythical Man Month, this is a must read for anyone working on software with more than one person. It covers all aspects the human side of software development and includes a wealth of information not only how how to manage software projects but also what environments work best for software development.
It's based mostly on research from the 1970s, but is still surprisingly relevant. The latest edition updates some of the core lessons for the internet age (e.g., substitute phone calls for email messages, and you get a similar break in 'flow').
-Chris
> (so how are we supposed to go about iterations, theorists ?)
Like you, I've written a number of template engines because I didn't like the limitations of existing ones (granted, this was in the mid to late 90s, so there weren't many to choose from).
After including iterators and conditionals in two different templating engines, I decided to try to design one without these programming constructs. I had seen too many UI designers find 'clever' uses for loops and conditionals and I wanted to see if it was possible to push them just out of their reach. I was also starting to see templating engines come out that placed unnecessary limitations on developers and wanted to see if I could strike a happy medium (fully enable good developers, properly contain UI people who thought they were developers).
The solution was a combination of JSP tags and XSLT. The attributes on the tags were designed to give the UI developers control over 'stateful' list generation (e.g., generate the first 10 items, generate items 5-10, etc...). The tags themselves generated an XML stream that the UI designer transformed into markup for the target platform (this app targeted desktop browsers, Palm Pilots, and old-fasioned WML-enabled phones). While XSLT does give the UI designer basic conditionals and iteration, there wasn't enough information available in the XML stream to do much harm and most UI designers could only handle basic transforms.
The key to making this work was careful design of the tag libraries that handled the program logic. In many cases, the tag libraries were actually implemented using JSP, with JSP used as a programming tool to generate XML rather than UI tool to generate UIs.
I'm sure there are some important details that have been lost to time, but in the end, the system met the goal of separating templating and control without sacrificing development flexibility (and, most importantly, without annoying the developers or UI designers).
So, it's definitely possible to build a full-featured templating engine that limits iteration and other programming interfaces. (and trust me, I had my doubts before designing the system)
-Chris
"The hard core ones use assembly."
Not on GPUs. The asm for any particular GPU line is not published and (according to sources at GPU companies) changes fairly often. Drivers that expose the GPU via OpenGL, DirectX, CUDA, etc. hide the programmer from this fact and allow the manufacturers to change the underlying hardware without changing the programmatic interface. These higher level APIs _are_ the assembly language for GPUs.
As an aside, this is the main reason CorePy (an Python-based assembly system I develop) does not support GPUs.
I'm sure the hard core people use assembly on general purpose processors, but I can guarantee they don't use assembly on GPUs.*
-Chris
*unless, of course, they're reverse engineering the GPUs and developing their own run-time system to execute the assembly language they've reverse engineered and doing this for every new release of a GPU. That's definitely hard-core, but usually good hard-core people are smart enough to know when they've gone overboard, hard-core young-uns excluded, of course.
There were some good points raised in the replies. I was definitely referring to Ivory Tower-type PhD students. Their job is research, not development. If they want to do development, they really need to rethink why they are in a PhD program. Any development they do should be to further _their_ research, not someone else's. This is a distinction often lost on people who haven't experienced graduate school. The research aspects of software engineering and computer science are very different than the development aspects. It took me about a year and a half into a PhD program (after years of working in industry) to realize this. Unfortunately, I still haven't found a way to easily communicate it to people who haven't been on both sides. Every now and then, there is value in a software-oriented thesis, but those that can become usable software while still making valuable research contributions are few and far between (projects like the Boost Graph Library fall in this category). And, those are usually personal, not collaborative projects.
CS/Informatics Masters students are an interesting case, especially at schools where a Masters Thesis is an extended software project. In this case, it's OK to partner with a student as long as you: 1) make sure the project you're doing is within their abilities and 2) make sure the time line for the project aligns with the the student's program. This is valuable experience for the student and their colleagues.
Physics, biomed engineering, bioinformatics, etc students are little trickier. In the case of Masters students with thesis projects, the comment above still holds. But, in these cases, it's important for everyone involved to make sure the best interests of the student are respected. These students are often lacking the software foundations that CS students have (not that CS students have much more) and require the proper mentoring from a good software developer in order to develop good habits. I've seen firsthand the effects of letting students learn to program without a good mentor and it's not pretty. The real risk here is that the software will not be scientifically valid - it may run and appear to produce good results, but without the proper oversight, there's no way to be sure if the results are valid. (again, this is true of CS students too, but the risk is higher when there are no experienced software people involved).
The most important point in this discussion, however, is this: Graduate school is for furthering education and, in a PhD track, developing research skills. Graduate school is not the place to do a software apprenticeship (that magical 0-3 years experience that gets you into the more interesting jobs). In most cases, the student is losing money by being in grad school and taking advantage of them as a source of cheap labor is not fair to them or the discipline of software engineering. Unfortunately, students rarely understand this and a number of professors actively exploit it. Of course, money isn't everything and there is something to be said for working on fun projects, but just make sure everyone's best interests are taken into consideration when entering into an academic development partnership.
-Chris
Developing software in a research environment is challenging. There are a number of constraints and conflicting interests that make it difficult for researchers unfamiliar with software to be truly successful. To make matters worse, the relationship between academics and professional software developers is almost non-existent, in large part simply because the research community has limited funds available for software development.
I've worked with a number of research labs to help bridge this gap and have developed a basic set of guidelines for developing software in research environments. In the end, the most important thing to do is draw a clear line between research tasks and development tasks. Understand what is in your area of expertise (research) and what is best handled by software engineers and other professionals. Then, depending on your resources, either hire a full time development team, a part-time consultant, or work with your university's IT staff to find local resources (many universities provide software development services). The place not to look is in the CS department: those students are there to do research, not write software.
I've put together a presentation that outlines a number of the challenges and how to address them. This presentation has evolved over the last 5 years based on a few ongoing academic research projects that have applied the ideas in it. Most of the ideas are standard practice in industry, but applying them to academic projects can be trick.
The slides are at:
http://www.osl.iu.edu/~chemuell/projects/presentations/vt-software.pdf
Good luck with your project!
-Chris
No! No! No!
CS grad students are in their program to do research, not develop software for other departments. Their time should be spent working towards their thesis. There is no research value in applying software engineering practices to develop an application for a researcher in another field. I know some schools allow theses along the lines of "A Software Framework for Cool Science Problem X", but these types of projects only shortchange the CS student. The projects are simply software engineering and should be handled by software engineers, not potential researchers.
There's also the problem that most CS grad students have never developed large scale software and are essentially in the "0-3 years experience" range. While they are usually very bright, they are not skilled practitioners yet. The code they develop will have all the same problems that plague young developer's code: little reuse, lots of reinvention, tendency towards trendy solutions (Oh! Let's do the whole thing as an Eclipse Plug-in/OO Framework/Scheme Interpreter/etc), and overly clever solutions. If the research wants to learn software engineering, their time is much better spent earning decent wages at a real software company with people who can provide proper mentoring.
Finally, there is the conflict of interest. A researcher's main goal is to perform research and publish papers. Software does not count as a publication. Thus, the software will be developed up to the point where there is something to publish and not much beyond. And, once the student completes their degree, they are off to greener pastures and support will quickly dry up.
So please: Stop using CS grad students as software developers!!! It hurts everyone!!!
-Chris
Working with rectangular regions is a breeze in emacs (very useful for quickly swapping columns in csv-type files):
Set the mark at the upper left of the rectangle... move the cursor the lower right...
Kill rectangle: c-x r k
Move somewhere else...
Yank rectangle: c-x r y
There are some other rectangle commands, but these are probably the two most useful "unknown" emacs commands I've come across.
-Chris
First off, I really appreciate the well-thought out comments to my original post. I was expecting some flame-worthy comments and am pleasantly surprised.
Now, to make this a proper /. thread and go completely off-topic...
I want to follow-up briefly on the NIOS idea, as it's one I've bandied about in academic circles for addressing the challenges facing researchers who need software for data management or simulation. The standard approach is to find a research angle and have a grad student develop the application in exchange for a degree. However, most disciplines are reaching the point where the requirements carry no legitimate research value or are simply beyond the skills of students. "A [OO|XML|Java|Perl|Forth] Framework for Baconian Dymanics" can only be published so many times before the reviewers catch on. And, it's not really fair for a student who should be developing research skills to spend their time writing boiler-plate code.
Some labs are able to secure NSF or NIH funding for software development. But, once they have the money, it's rarely spent on professional developers. Instead, it goes to the lowest bidder (or a colleague's kid who learned HTML in high school) and the quality of the software takes a big hit. And, most scientific PI's have difficulty effectively managing software projects.
It seems that the NIH/NSF could invest in a National Software Institute that provides developers for academic projects. The trick would be not to become a typical consulting shop and instead develop long term relationships with the labs while building out shared frameworks/toolchains/(pick your favorite abstraction technique) that can be used across similar projects. It would also be important to hire developers who were interested in science and would take the time to understand the domain they're supporting. And, it would be essential to develop reliable QA and validation practices to ensure that the science they're supporting is reproducible (something that most people I've worked with agree is lacking in most scientific software).
Anyway, some of the foundational ideas are worked out in a talk I put together and have given to a number of different labs. It's more focused on how to get individual labs implementing good software development practices, but I've always wanted to see the core ideas scale to a larger service organization. If anyone's curious, the slides are at:
http://www.osl.iu.edu/~chemuell/projects/presentations/vt-software.pdf
-Chris
This raises an interesting point that I'd like to see /.ers discuss:
Without the charity of well-to-do geeks or companies that fund open source development from profitable product lines, can Open Source succeed at the enterprise level?
This thread is a good example of the first case. Sun/Open Office, the Google/Mozilla "relationship", IBM, et al./Eclipse are examples of the second as is the general practice of different companies employing Linus, Guido and a few other key people to keep Linux/Python/etc going.
Without the strong investment from those with deep pockets, can Open Source software progress at the rate needed to remain viable in the enterprise? What happens when the product lines funding those projects start losing money?
If you respond with counter-examples, make sure you do a proper accounting of who is really doing the development work on the project. Is it people in their spare time or is it paid workers being funded by the revenues from other projects? And, of course, focus on Open Source software that is being pushed and is _viable_ for enterprise use - hobbiest level software and boutique libraries will always have volunteers available.
-Chris
Also, keep in mind that for data-intensive, I/O-bound HPC applications (think next-generation genome sequencing and "personalized genomics"), efficient use of large amounts RAM is very important. In fact, many of these applications are bound by the cost of RAM - while they could benefit from 256 GB, the cost is currently too high (I know: I just tried to justify purchasing such a system). Good programming is very much a requirement for these applications (though the practitioners in these fields are only starting to realize this).
The Cray CX1 is an interesting entrant into the market for these types of applications. The only major drawback is the limited amount of RAM per node. They should support at least 64 GB and ideally up to 256 GB (I know the summary says they support 64 GB, but the order page only allows up to 32 GB/node). Oh, and I want 20 TB of fast disk along with 8 compute nodes, not in place of 6 of those compute nodes. :)
-Chris
From the second paragraph of the actual report (not the founder's letter):
Now, please explain why Google would ever want to enable ad-blocking or even make it easy for a third party to do so. If Chrome had a large market share and ad-blocking was enabled, Google would be toast.
-Chris
My point has nothing to do with government limits or anything like that.
What I mean is that by Google using this as their primary data source and with 50 cm being "good-enough" for a lot of applications, there will be less incentive to invest the better aerial data. It's just the simple fact that once the market is flooded with 50 cm data, most people won't know that there are better resolutions available and most consumer applications will be built around 50 cm as the standard.
If Google used 40 cm or 6 inch data, the same would be true. I just worry that we'll be stuck with 50 cm data for the foreseeable future because of this. (and I'm greedy and want the world at 6 inches!)
-Chris
Well, it's not really news. If you understand the different data sources, it should come as no surprise that these images are not as good as the high-resolution aerial photos and as good as good satellite photos (think of the before/after tsunami photos)
Good aerial photos have a pixel resolution of 6 inches. Decent ones are 12 inches. GeoEye-1's resolution is 50 cm, or about 19 inches. 19 inches is good for working with large objects, but not useful for fine-grained measurements. (it will be fine for 99.9% of the apps Googlers develop)
For a good example of 6 and 12 inch data, look at the state of Indiana (in the US) in Google Earth. In 2005/6, Indiana re-imaged the entire state with aerial photos. The whole state is at least 12 inches and all metro areas are 6 inches.
I'll be really excited when we can get continually updated 6 inch data... My only concern is that with Google's dominance, we'll be stalled at 19 inches for a long time and people will start to think that's the best we can do.
-Chris