Jump to content

Justin Goeres

Members
  • Posts

    691
  • Joined

  • Last visited

  • Days Won

    10

Posts posted by Justin Goeres

  1. QUOTE (crelf @ Nov 16 2008, 07:20 PM)

    You got something better? Seriously, if you do have something better, or even an idea on how it could be improved, I'd like to see it (and, I'm sure, so would NI). Personally, I think that the report generation toolkit is pretty damn comprehensive.

    PS: I don't think that a day perfecting a complex report isn't unreasonable.

    My problem with it is that it's hard to extend the library. Especially now that they've refactored it to use LVOOP, the ActiveX reference to (for instance) the Standard Report is really tightly encapsulated as private class data. Without that reference, you can't do anything to the report except what NI chooses to expose.

    If they're going to do the Report Generation in LVOOP (which I think is a good idea, btw), they should expose the report reference through a Protected VI so that users can easily add a child class of NIReports.lvclass (or whatever they call it) that modifies or extends the behavior for their needs without modifying things in vi.lib. That's one of the bullet-point features of LVOOP! :wacko: In the current implementation, everything is really locked down :thumbdown:.

    Other than that, though, I like the library just fine :P.

  2. QUOTE (ASTDan @ Nov 13 2008, 10:50 AM)

    Specifically is there a way to control the size of individual columns

    I have a VI somewhere that does exactly this. I will try to dig it up (and clean it up) this weekend and send it to you.

    Regarding changing the font of individual cells in a table -- I've never tried to do that, but I think it's possible.

  3. QUOTE (ASTDan @ Nov 4 2008, 08:00 AM)

    Wow thank you for sharing you journey. I just have an external drive I back up all my critical data and store it in a waterproof/fireproof safe.

    You have given me a lot to think about. :worship:

    No problem. Data backup has become sort of a pet issue for me, because I think far too many people are really living on the edge and taking risks with their important data. It's really, really worth the time to set up a backup system. Think of it like buying insurance, but for your data. And if you do it right and get something reasonably automated, you can stop worrying about it. That's the real hidden benefit :).

    Actually, the fireproof safe is a good idea! I have a safe already and could buy a new drive. I think I could create another backuppc task to another drive, and it would only run when that drive is connected. Then I'd just have to plug the new drive in every month or so, leave it overnight, and put it back in the safe. :ninja:

    EDIT: BTW, when I started making notes & buying parts for this, I got a little bit of the old "OMG what's this new contraption?" thing from my wife. I sold her on it entirely based on the we never have to worry about data backup again angle, shortly after she lost some of her old PhD. work in a USB key accident :blink:.

  4. I wanted to answer the rest of your question more fully :P.

    QUOTE (ASTDan @ Nov 3 2008, 07:29 AM)

    What do other people use for their backup method? What software do you use? Why do you use it? What are the pros and cons? What backup medium do you use and why? Are there any backup best practice guidelines?

    When I was working independently, I took some time to figure out a backup solution for my business. It's really worth the peace of mind to do it right, and it's not that hard considering the value of the information you're protecting (whether it's personal financial data & family photos or company IP). Here's a summary of what I did. This served me well while I was in my own business, and now is doing an equally bang-up job for my personal & family data.

    Level 1 / Windows Workstations: All project work (this includes work projects and any "personal projects" where rev control is useful) is checked out from an SVN repository on the Server. Non-project work (like Invoices, Expense receipts, etc.) is stored on network shares provided by the Server, and are mirrored locally using the built-in Windows Offline Files feature (this makes it reasonably easy to carry work with you when you travel, and sync changes when you come back, as well as providing redundancy).

    Level 1 / Mac & Linux Workstations: All project work is checked out from SVN as on Windows, and all systems use the same network shares as the Windows machines. However, because Windows Offline Files doesn't exist for the Mac, some non-SVN user documents are stored locally. All user data & system configuration data is backed up nightly to External Backup (see below) via SSH.

    Level 2 / Server: A Linux box (but it could be any OS) providing an SVN repository and SAMBA (SMB) network shares. Each user is provided with a "home" directory, and I also have "family" and "public" shares with permissions set for family members and visitors/friends. The main data storage on this machine is a 600GB RAID5 array (3 drives of 300GB each). SVN & Windows Offline Files provide redundancy for the data served to the workstations, and the RAID5 array provides resistance against data loss due to drive failure. FYI, I built this machine for about $600 two and a half years ago, and that even includes buying a super-fancy case (which was totally worth the money). It took a few days to get it built & working, but I learned a lot doing it. This machine (and the network router) are plugged into a small UPS, that provides about 20 minutes of power in case of blackouts.

    Level 3 / External Backup: Data on the Server itself is backed up (using backuppc) to an external Firewire drive attached to the server. All user data, fileshares (including SVN repo) & OS configuration data is backed up each night. 7 previous incremental backups and the last 2 full backups are stored. This provides another level of redundancy for the data on the server, in the unlikely event that the RAID5 would ever fail. It also provides a brief historical archive, to guard against accidental destruction of files that aren't under SVN control.

    Note that this system provides 3x data redundancy (2x for non-SVN data on the Mac :( ) for all user & project data. That's the critical data you create that, if you lost it, would be right up there with having your car stolen. Except that you can probably buy another car. You can't buy replacements of your wedding photos or your hundred-year-old great grandma. There should really probably be a Level 4 / Off-site, but for the time being I lock the doors of my house and just pray it doesn't burn down. And if it burns down, I'll have other problems equal to or larger than granny's missing pictures.

  5. QUOTE (ASTDan @ Nov 3 2008, 07:29 AM)

    As to whether a backup system will cause problems with your repositories, the answer is not if you do it right .

    I run my personal (non-JKI) SVN system on an Ubuntu Linux box in my office. For backups I use http://backuppc.sourceforge.net/' rel='nofollow' target="_blank">backuppc. It backs up all the data I need backed up on my server, and also backs up my MacBook Pro via an SSH tunnel (which, in principle, would even work over the internet when I'm on travel).

    On the Linux box, one of the directories I point backuppc to is the one where SVN keeps its database. SVN is really just a frontend to a database, and the database is where the filesystem of your repository lives. As such, if you make sure to backup the whole database then you can also just restore the whole database in the future after a catastrophe. Of course, I also back up /etc, which is where SVN keeps its config. So basically, my advice (regardless of platform) for backing up your SVN repository is to (A) make sure you back up the whole repository, which is pretty easy because it's contained under a single directory, and (B) also back up whatever directory contains your configuration for SVN, so if you have to recover you can reset to a good config, too (otherwise you might have to remind SVN where its repo is, who its users are, etc.).

    It goes without saying (but I'll say it anyway ;) ) that once you start backing up your repository (which you should!) you do not need to backup your checkouts. In fact, I personally don't backup my checked-out SVN directories specifically to encourage myself to commit frequently :P.

    EDIT: I do not know much about using backuppc with Windows machines. In my case, any files that I need backed up in Windows are stored on network shares from the fileserver, which is backed up. Backuppc supposedly works with Windows, but I've never bother to try it :P.

  6. QUOTE (BrokenArrow @ Oct 28 2008, 12:25 PM)

    Thanks jdunham. I think you are spot on. I don't have the code with me at the moment, but the state machine takes us back to Idle where there's a Bytes at Port that runs once every few seconds, maybe that's what's reopening the port. I bet that's it. I need to wrap that in a False statement if the user has tried to re-link to the port.

    It could also be caused by poorly-written drivers for your USB-to-serial converter (or serial-port PCI card) if you've got anything like that in the loop.

  7. QUOTE (Norm Kirchner @ Sep 10 2008, 12:24 PM)

    Take some damn perspective on this tool, it analyzes what things are and moves them around in a logical manner.

    This is one of the most creative ideas that I have in LV in a long time.

    .... I can't even get what I'm saying across right at the moment because I'm so beside myself that you are all so critical of this awesome feature.

    The tool doesn't probably care how special you are and how neat the code is already. More likely it says what the F did y'all plop down and what makes sense as far as layout and starts from scratch.

    I don't think anyone's really being all that critical of it. It takes what seems to be a pretty hard problem and comes up with generally fairly reasonable layouts. I think it's interesting to consider, though, that the tool will always be the product of a few developers' ideas of "good style," boiled down to a set of heuristics. NI has done a really good job on it, but that doesn't mean it's not interesting to look at the cases where it comes up short anyway.

    And FWIW, I'm actually kind of impressed by how little it modified the examples above :P. You can kind of see by the changes it makes how it weights different nodes and different wiring patterns.

    For the sake of argument, though, the handling of free labels is really inconvenient. For the large number of us who use free labels to label our wires, we either have to change our workflow to do the labels after a cleanup (which means they're not labeled during initial development :wacko: ), or resign ourselves to replacing them all the time :blink: , or just never use the Magic Fingers :( . For such a banner feature that it got airtime at an NIWeek keynote, that's a bit disappointing, and that's not its only shortcoming.

    I still think it's pretty clever, and reasonably well executed, and a godsend for a large number of LabVIEW developers. But the problem it's trying to solve is fundamentally pretty hard.

  8. QUOTE (Aristos Queue @ Sep 10 2008, 05:23 AM)

    Justin: Did you play with any of the Tools>>Options settings that control this tool? The default setting is to compact the diagram as tight as possible. In general, all of the user written diagrams have a "looser" feel to them. Try increasing the spacing setting and see whether that improves results.

    Good point. I didn't change any of the default settings. This is fresh-from-the-shrinkwrap behavior.

  9. For fun (and inspired by our other discussion), I decided to apply the Block Diagram Cleanup Tool to several examples from the 99 Bottles of Beer thread from a while back. I picked 3 VIs from that thread to run the tool on. I didn't pick these for any particular reason, other than that they're all reasonably different from each other. I opened them in LV86, took a "before" screenshot, then ran the Cleanup Tool and took a "after" screenshot. I didn't do any cleanup of the "after" code, other than that I removed some free text labels (which had been scattered to the wilderness areas of the diagram, because we already know those aren't handled well).

    On balance, I think the Cleanup Tool generally made these VIs worse in terms of readability, particularly near the Format Into String primitives. At the very least, I don't think it improved them much, if at all. And while these are non-trivial VIs, they're not terribly complicated. So what's the deal? Were these VIs just pretty "clean" to begin with? What do y'all think?

    Aristos Queue

    BEFORE

    post-2992-1221046129.png?width=400

    AFTER

    post-2992-1221046135.png?width=400

    Orko

    BEFORE

    post-2992-1221046171.png?width=400

    AFTER

    post-2992-1221046177.png?width=400

    Justin Goeres

    BEFORE

    post-2992-1221046149.png?width=400

    AFTER

    post-2992-1221046156.png?width=400

  10. QUOTE (Aristos Queue @ Sep 9 2008, 02:59 PM)

    Did you see Darren's demo in the NI Week keynote? He dropped a bunch of nodes fast using Quick Drop, didn't care about where he dropped them, wired them up (with some wires running backwards) and then hit the clean up button. I've seen a number of programmers do this. I don't know how widespread it is. I've tried using that strategy myself recently, and the results aren't too bad.

    But Darren was also coding an exceedingly simple VI. I've tried to use The One True Tool on other VIs that are really still pretty simple (inputs: a couple of LVOOP objects, maybe a DBL and an error cluster; outputs: an LVOOP object & error cluster) but that include a couple nested cases or loops with shift registers, and it makes some really eyebrow-raising decisions due to its obsession with the error wire. Generally I'm a big fan of straight error wires, but except in the simplest VIs, it really makes odd decisions.

    Also, I tend to arrange my block diagram terminals so they roughly match the connector pane of the VI (not by distance, just by top-to-bottom order on the left & right sides of the diagram). The block diagram cleanup tool does not share this preference, which puts it strongly at odds with a key personal aesthetic. So are the diagrams cleaner? Sometimes. Are they more useful and easier to understand as I drill down through a chain of subVIs? Usually not :unsure:.

    Now, that having been said, I think it's a great tool for people who don't already have a decade of personal style worn into the faux-woodgrain of their desks. It gives them a chance to see what their code would look like, if it were reasonably clean, and that's a big step forward. The cleanup performs so well on simple VIs, in fact, that I can see Quick Drop as being something that encourages users to write not cleaner diagrams, but simpler diagrams. And that's good for everybody :thumbup: .

    QUOTE

    It's below my standards for a clean diagram, but not by much. We shall see how this goes in the future, but it would not surprise me to see, over time,
    LV
    style end up matching what the code clean up tool creates. As layout quality improves, I think that many programmers will decide to let the tool handle the layout rather than nudging nodes pixel by pixel.

    I think that this could be true, but it will require NI to put real effort into refining and continuing to develop the block diagram cleanup. It's pretty surprisingly good for just having come out of the gate, but I'm afraid it could be seen by NI as "good enough" and just allowed to languish. Or worse, NI could devote more resources to it in lieu of fixing other, worse problems in LabVIEW, and leave us all with shiny, clean, lickable block diagrams that still don't do what we want ;).

  11. You forgot one. :P

    Newcomer

    Accepted to KinderGarden

    Primary school student

    Secondary school student

    High school student

    Freshman

    Sophomore

    Junior

    Senior

    Graduate

    Postdoc (PhD)

    Adjunct Professor

    Associate Professor

    Professor

    Professor Emeritus

    alfa

  12. QUOTE (HChandler @ Sep 5 2008, 08:58 AM)

    Well. the part I'm mad at them for is not giving the developer more control of what gets linked to what.

    You have all the control you need. But like Yair said, the problem stems (mostly) from the fact that LabVIEW can't simultaneously have 2 VIs in memory with the same (qualified) name. This takes some getting used to, but honestly, for the most part you're feeling helpless right now because you don't yet know how to use the tools that are in front of you. Everyone goes through that at some point, with every new language.

    QUOTE

    Admittedly, I'm a babe in the woods when it comes to
    LV
    development, and I should have laid a better foundation. Still, I would much rather deal with a Makefile than the interminable dialogs and "stuff being done because it was programmed that way by someone who's assumed (and you know what that means) that everyone is on the same page with regard to programming style.

    And I would much rather deal with LabVIEW's project windows, VI hierarchy, and linking behaviors than cryptic Makefiles and 10 pages of compiler warnings/errors. It's all a function of what toolset you're used to working with, and the discomfort you feel when you move to a different workbench.

    QUOTE

    Or should I say styles. Like everything in labview, I've got a million ways to screw myself over. I've got the project, llbs, lvibs, all of that OO stuff, project folders (auto populating and virtual). I have very little determinism. Too much gets done for you, and in ways that you might not want to have happen.

    Actually, it's generally very deterministic. Unless you're misusing the word?

    That having been said, I can sympathize with you. LabVIEW is pretty aggressive about the way it tries to resolve subVI linkages, and even though the dialogs and warnings you get are a lot more helpful than they used to be (there was a time when there were no cross-linking messages -- it just happened invisibly!), as a novice user it's hard to understand when you've gotten yourself into a ditch until you've driven several miles in it.

  13. I just discovered Zoë Keating today and immediately liked her stuff well enough to buy her album from iTunes (or, if you prefer, Amazon's MP3 Store, or even the old-fashioned way).

    As described by a post on BoingBoing:

    QUOTE

    "The excellent Radiolab podcast recently featured Zoë Keating, a classiclly-trained cellist who now makes absolutely entrancing loop music in real time using digital samplers. Radio Lab host Jad Abumrad referred to Keating as the 'quantum cellist' and her rich, layered, and haunting music has been described as 'the perfect music for apocalyptic landscapes.'"

    So I was looking at my block diagrams, and thinking, "Apocalyptic landscapes? Sounds about right...."

    Or maybe I have a thing for cellists with dreadlocks?

    QUOTE (crelf @ Sep 3 2008, 06:47 AM)

    I agree that The Internet has become something that should be personified
    :)

    I'll let it be the judge of that.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.