06.17.2014 13:39
Argo Floats
Earlier this year, Michelle made a
super cool vidoe about Argos Floats.
The floats are popular and there are other videos out there.
The floats are popular and there are other videos out there.
06.17.2014 10:35
Looking at large diffs
Here is a little Unix command line
trick. I've been looking at the differences between version
releases in software like GDAL, HDF4, HDF5, etc. There is often a
lot of noise (aka non-functional changes) that get in the way of my
trying to understand what is different. The diff tool is pretty
useful and I often look at diffs in emacs and appreciate the
highlighting of Diff mode. However, I'd rather not have this noise.
In the case of GDAL, that is a lot of copyright and svn Id changes.
Those don't change the bevior of the code. Here is how to get them
out using the diff ----ignore-matching-lines (-I) flag. Just repeat
the flag for each thing you want to not get used for diffs. e.g.
diff -ruN gdal-1.1[01].0/port -I 'Copyright' -I '$Id:' > port.diffThat says to recursively produce "unified" format diffs with the contents of new files shown, but leave out lines with "Copyright" and "$Id:'. The two -I flags drop the diff file from 7500 lines to 6200 lines for the changes between GDAL 1.10.0 and 1.11.0 in the port directory. Every little bit of help makes things easier.
06.12.2014 08:35
US fishing and passenger exemption for greater than 65 feet
I didn't realize that this exemption
is in the USCG AIS Carriage Requirements (emphasis added):
AIS REQUIREMENTS - Title 33, Code of Federal Regulations - 164.46 Automatic Identification System (AIS).
- 164.46 Automatic Identification System (AIS). (a) The following vessels must have a properly installed, operational, type approved AIS as of the date specified: (1) Self-propelled vessels of 65 feet or more in length, other than passenger and fishing vessels, in commercial service and on an international voyage, not later than December 31, 2004.So, if you were a 1000 ft fishing ship in US waters, you don't need AIS. Not that there are any fishing ships that large. Any why passenger vessels? It also looks like passenger vessels also get a pass, but if they enter a VTS area and have 151 or more passengers then they have to have AIS. So weird. These rules are so poorly written. Why in the world do we still have the dates in the rules when those starting dates are 10 years ago? I guess the USCG has no concept of version control.
AIS REQUIREMENTS - Title 33, Code of Federal Regulations - 164.46 Automatic Identification System (AIS).
06.11.2014 09:34
IOOC DMACS
Today is the start of a multi-day
Interagency
Ocean Observation Committee - Data Management and Communications
Steering Team (IOOC DMAC) meeting. Sadly, I've always been a
remote attendee as the rep from Google. I've been struggling with
the question of how do we all, meaning the entire community, and
especially the one actor I can control - my self, have the greatest
positive impact on the future of the ocean sensing / observing
community. It's a challenging question. All participants were asked
a bunch of questions beforehand.
Sometimes people feel that they are not some big powerful organization and that they have no influence on things. As a grad student and as a professional, I have felt the weight of bureaucracy and the in-elasticity of people have been doing things one way for years. What can each individual do? Turns out that any one person can do quite a lot. Here are some thoughts and I'll try to make them actionable.
Sometimes people feel that they are not some big powerful organization and that they have no influence on things. As a grad student and as a professional, I have felt the weight of bureaucracy and the in-elasticity of people have been doing things one way for years. What can each individual do? Turns out that any one person can do quite a lot. Here are some thoughts and I'll try to make them actionable.
- Try to stay positive in interactions with others. Technology and science can be frustrating and confusing. Try not to let that creep into interactions with others. If someone flames you, do not flame back. Especially when doing things like writing a bug report or a response to a bug report. On the other hand, do not let that keep you from being direct.
- Report bugs in any software or hardware that you use (be it open or closed). Strive to write clear bug reports that make it as easy as possible to figure out what version of things you are using, what are the symptoms, and if you think there might be a solution, try to explain what it might be. Include a picture, screenshot, code, or data sample whenever possible. I've gotten lots of "It doesn't work" bug reports and then I have to ask back, "What does not work and how is it not working. Whenever possible, have these bug discussions out in the public where others can learn from it. If search engines can't find the info, then there is little value in it.
- Learn to program and read open source code. Maybe you never will feel comfortable submitting a bug fix back to a project, but hopefully you will. Even if it is a spelling fix in a comment, your help is immensely important.
- When writing code (even small couple line programs), use a style guide and write clean code. How you create data and write code is just like formal technical writing. You might be annoyed by some of the things in those guides, but they are in there because other people have long suffered with bad code and have specific reasons for almost all of those entries in the guides. e.g. While it may be cool to have single letter/symbol variables and operators in the land of mathematics, but that does not work well in software.
- Really dig into taking notes as you work, put more energy into writing up the methods for you use, and get them out to the world. So few papers out there (including my own) have enough info that someone else could get the same results. It's hard, but we have to strive for it.
- Stick to open data formats and standards whenever possible. Design by committee sucks, but design by yourself in a closet is just as bad. If you have to make something new, get others to review it who are domain experts before committing to strategy. You don't have to take there advise, but you should ponder what they are saying.
- Be willing to admit mistakes and errors. If we all were perfect, then we wouldn't be humans. Improvement and learning go best when we use mistakes and errors for learning. Think constructive criticism and avoid the destructive type.
- Learn from everyone. Everyone is accustomed to newer people learning from experienced people, but it really is a two way street. People who are new may find a different and possibly better way. Or the trouble they have may inform the experienced folk as to what needs to be changed or better explained.