Jump to content

dannyt

Members
  • Posts

    416
  • Joined

  • Last visited

  • Days Won

    12

Everything posted by dannyt

  1. Jim, I sometimes wonder if you should get out a little more Just to tie in a previous thread covering this topic.
  2. Hey great this now works OK for me as expected. It looks like the Bug fix yesterday on LAVA changed this. I am happy if you want to close this off now as fixed :-) many thanks Danny
  3. dannyt

    Hi!

    Hi Welcome to LAVA
  4. I do totally understand where Aristos is coming from with this comment, that NI need to make money to pay for their developers etc. But as my LabVIEW experience grows and I do more and more LabVIEW both at work and occasionally at home, I do feel I am doing the wrong thing because as an individual developer or "home enthusiast" programmer the cost of LabVIEW is out of reach. So the more LabVIEW is do, the more time I spend on it leave me more exposed I sometimes feel I become. Dannyt
  5. Hi, I noticed on the View active topics page are the bottom their is an option Active in the last ...... option with options of <24hours> <week> <2 weeks> etc. But only the 24 hours selection works. If you select <week> and hit GO .... it looks like it correctly finds all the results as it come up with 3 pages of results showing page 1, but if you try to go to page 2 or 3 it sets itself back to 24 hours so they can never be seen, I see this in IE6 and Firefox 3.5.3
  6. Hi we use the same branch - modify - merge pattern, we only have six developers here and the only advice I can give really is communication between the developers. That said some guide that help us (and only help they do not solve the problem) are : we do have a simple web tool so at a button click anybody can see what files other people have out on branches (very useful) Plus we try and keep the work / architecture spilt but it never really works. merge often / merge often. This is key and also relates to branches on text code. Keep branches as simple as possible and merge as often as possible. I strongly agree with this if one of use is doing a change that will result in lots of recompiles we plan that change in with everyone else. This is the one MAJOR problem I have with LabVIEW and to me it is a major problem. It is bad enought with six developers I cannot even imagine what it would be like with 50 + developers and yet this pattern works fine with 100+ developers with text languages...ah well not point in wishing it will go away. Dannyt
  7. Hi, We have been doing code reviews QCP's (quality Peer Reviews) for a long time now on all our "new" software and "software changes". Our process is based on one we use site-wide for C++, C (30 + develpers) and LabVIEW (6 developers). I have uses this same basic process for many years at different compaines It is done as a formal traceable process, built into our own web based tools that we use to control ClearCase our source control tool. The web based tool we created and use acts as a both records keeping system, who was the reviewer, log of review comments (and developer responses) and process machine, controlling when a QCP (quality Peer Review) needs to be done. When do we do a QCP All software written, bug fixes /new features and carried out on separate ClearCase branches. Each ClearCase branch is atomic, ie it contains all the changes for that bug fix or whatever. The developer tests and codes on that branch and at bthe point the developer is happy that the code is ready to go into the ClearCase mainline (ie ready for everyone else to use or be released) a QCP will be done. So ALL software is peer reviewed before it is added into the main code stream, this is control by our web tool which will not allow a merge back into main until a QCP has been passed. Note a branch could have one file on it or lots. Typically a branch is kept small in scope, even for new major new software we would try to built it up a bit at a time with a different branch for each bit. This is partly to make the peer review of a branch more manageable. In LabVIEW we only really get big branches when we have major recompile issues. A branch status goes : development - ready for QCP -- passed QCP (or back to development) QCP levelsOK we all live in the real world and not all software changes are equal, plus sometimes pragmatic decisions are needed, "FIX THIS NOW" so we have some different level of QCP that are carried out. Our QCP levels are None - very rarely used level , must be accompanied by a good reason for this type of review, maybe a save due to recompile only Maint - just a quick check over the changes made. High - examine the changes made and their context. Detail - same as above really possible we do not need this option Demo - show the review the change in action The key here is that, the information is recorded (so traceability) the developer has to think about it. I would say that 99.9% of reviews are done as high /detail What happens in a review First off, during a review it is the developers responsibility to satisfy the reviewers comments or questions, after all it it the review that passes or fails a QCP. If a QCP passes then the code is merge into the mainline and the branch is closed. If a review fails the branch goes back to a development state and the developer needs to address all the reviewers comments. A reviewer will do the following for all reviews except the None type. 1) Load all the top relevant top level VI's and ensure that a) there are no broken run arrows b) they close with no save's needed. 2) Run the VI analyser on all the files on the branch. We have this automated and the analyser config spec set to our custom requirements. All failures will be visually examined. We have a document which deals with the analyser results, which must be fixed / which should be fixed (or explained away) which we can ignore and in what circumstances. We use the VI analyser as a style guide tool. 3) The reviewer will use the OpenG compare to disk tool (modified to work with LabVIEW 8.2) to visually look at the code changes between the current version on main and the ones on the branch under review. For a high / detail review (our normal review type is high) the review will also look at the wider context of the changes and how they fit into the general scheme of things, how they meet the requirements of the change or bug fix. Any comments the reviewer makes are logged. If the reviewer is not happy with the code the branch is set back to development status, the comments are mail to the developer who must then, explain / justify a code change or modify the code. Being a smallish team, often the reviewer and developer will sit together during a review so typically when a review has failed the reviewer and developer have already agreed on what corrective action is required to pass next time, but the comments and reply's are always recorded. Following a failed peer review, the developer does their changes and any retests again (weell the code has changed) and then resumits the changes back to the original reviewer for a new QCP, hopeful it will pass this time :-) Other comments I would like to get some automated unit testing built into this system but it is a while before that will happen. Having done QCP's for many years, I can honestly say Iwould not develop software in ANY language without a peer review process of some sort. The value of getting somebody else to view your code cannot be over stated. Just from a simple style point of view if nothing else. When you KNOW somebody else is going to look at your code with a critical eye you tend to write your code differently. Nearly every code review results in a valid comment that will improve the code, this is NOT to say the the original developers was poor or lazy, just a different view is taken by the reviewer, in some case our peer review has stopped code going into our mainline that would have been a major problem if it had got released. Finally, I did see a really good NI webcast Performing Technical Code Reviews to Improve LabVIEW Code Quality but though I found a link to it at the bottom of the page it seems to now be removed I hope this makes some sense and is of some use cheers Dannyt
  8. dannyt

    Pun

    I also had to be spoon fed the answer to this one.... duh I feel pretty lame now
  9. quite right well noticed :-) or you could use ..:..:..\s(A|P)M well I did say to "play around a bit" dannyt
  10. Morning again. Couple of things first. I strongly suggest you read a little about regular exp​ression and how to use them, then have a play with them. They are very powerful for this type of thing involving a predictable pattern and splitting it up. Try Regular exp​ressions and look at the LabVIEW help for the "match regular exp​ression's". I would also suggest you would be better working with a 24 hour clock system rather than AM and PM, from past experience I think using AM and PM will lead you to nothing but woe; when you come to get data out of the database and analyse the results things can get messy. Also where are you getting your time from if you are using LabVIEW its self then you would be better using the LabVIEW timestamp type. Anyway some example below that might help you cheers Dannyt
  11. Hi, It all depends on what you want to actually do with the split parts afterwards, there are several ways to skin this cat, typically you use the match pattern, match regular pattern , split string function in a while loop until you find no more matches. you can also do it all at once using the spreadsheet string to array.
  12. Many thanks Daklu, that is exactly what I want sorry for wasting people time I had missed it up by the RSS feed.
  13. Hi Guys, I was away from a PC for the last part of last week (a great time at the Bristol Balloon festival). and with NI week going on I wanted to go over last weeks posts. I really like the short-cut to Today's active posts on the portal page. But in Lava 1.0 I remember there was an easy way just to roll back over all posts in time so it was relativity painless to see all the post during the last week. To do this now it seems I have to go through all the forums one by one and go back pages in each. I do not know if this would be possible / easy to implement or if anyone else would find it useful cheers anyway Dannyt
  14. gentle bump. I just wanted to know if you thought this was working as you yourself expected ?
  15. Thanks for the replys, I will have to give it a little more thought. Danny
  16. Hi AQ, I do not mean to take this thread of topic but your comment "You can kill an app's performance by needlessly using references of any kind" made me stop and worry exactly what you meant and in what context . I have started to rewrite some very old systems here using a mixture of the JKI State Machine and a parallel user event loop. Until now I was feeling quite pleased with myself, I felt it look good code, was following a good pattern, however now I am not so sure. On my top-level front panel I have quite a few controls and indicator a number of which need updating from lower in the code (as we all often do). A lot of my style to tidy things up was to cluster common control / indicators together, I would then create references to these clusters and other controls / indicators on the front panel. All these references would then themselves be clustered together and, in the JKI state machine world these clusters of references would then going to shirft registar so they could be accessed everywhere by just pulling them out of the cluster as and where required. Your comments abvoew make me thing this may be a very bad way of doing things. Could you please expand this maybe in a new thread cheers Dannyt
  17. dannyt

    Wired wires

    I am beyond words It time for me to lay down me mouse and crawl away from LabVIEW my little head hurts now Still I see a new edition of peter Blume's LabVIEW Style Book will be needed Dannyt
  18. Well just to stay of topic, a lot of that was filmed last year down in Cornwall and Devon, a friend of mine who is a school teacher took one months unpaid time of to be an extra in the film. She said it was a very interesting but bizarre experience.
  19. Hi Admins, Sorry to go on about this, but I am not yet clear about it. Do you consider the search function as it exists to be functioning correctly as expected in terms of the + (AND) option or if this a bug ? cheers Dannyt
  20. Opening book to those pages and reading now, thanks. Does mean skipping forward as I am only really on page 98 so far cheers Dannyt
  21. Good day all, First off, though this post is sort of based on the JKI state machine, I have posted it on Lava as it really covers a wider and more general question of design patterns and therefore, I want to open it to a wider audience I have to opportunity, to rewrite our top level VI for our Test Executive. It currently has a number of separate polling loops to check for user events, and it works on a basic state machine principle, though not to any of the now standard design patterns. I am after something that would allow the UI to be responsive to certain actions even while a long test sequence would be running underneath it. I have spend some time looking at various patterns like Queued State Machine and also the JKI State machine , I do like the simplicity of the JKI state machine and have used it once on a sub-project that went very well for me, however it as it stands will not suit this situation.... or so I though ... and I really need something like the queued state machine. Now my question is this, I was reading a thread on the JKI state machine and something there really hit me... "First, you might want to consider using LabVIEW User Events for passing data instead of queues, that way your UI will never be polling" This brings to mind a Producer / Consumer pattern bases on this idea, whereby both the Producer and Consumer are simple state machines with the Producer generating user event that the Consumers looks for, JimK talks specifically about this pattern in post 10 of the above thread. I really like this idea and I am thinking of trying it for new rewrite, I just wondered about people thoughts and comments on this as it is not really a standard design pattern. cheers Dannyt
  22. There is a whole world of difference between the LabVIEW Probe and Highlight Tools and Unit Testing. The former are aids to help you find and debug problems, the later is the basis of a whole software methodology. I have not yet used and Unit Testing in LabVIEW but I have see extensive benefit's of its use to other projects. One key benefit is Regression Testing, how do you check that what you change today does not break something that was working yesterday. I once worked on a very large C/C++ project (100+ developers) that was was run under the Agile Software Methodology. Before any code was written the Unit Test Software for that code had to be written. When a developer finished some code and checked it into their source control system we used Curise Control to automatically do a build and run the full test suite on the software, if any tests failed automatic emails were fired off. With this system we know within an hour that something that used to work had been broken, and it was easy to find out what changes cause that break. So as I said at the start there is a whole world of differnce, between these tools. Dannyt
  23. This statement is not totally true. Yes you do need to create a LabVIEW Project Explorer with the top-level executable, if you are doing a straight NI LabVIEW build, however if you are using the OpenG Builder then you can happily build without using a LabVIEW project and there are many good reason to use the OpenG builder in my view (Note to self .... I really should start using the LabVIEW Project Explorer ) If you do use the OpenG builder you will still need the NI Application Builder as this is at the core of the OpenG builder. Dannyt
  24. Hi Vane, I am not to sure I really understand what your question is here, could you exand it a bit please. Are you running the LabVIEW development environment on both the PC's ? and you just want a method for both VI's to know the absolute path to these shared folder is ?
×
×
  • Create New...

Important Information

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