Leaderboard

I have been toying around with a more radical UI design change. First of all, I am not a big fan of tab control. Secondly, I want to try to get a UI customizable enough that it can cater to as many people as possible. Here is what I came up thus far (note: this is mostly just a UI mock up and it has very little functionality). <object width="1068" height="546"> <param name="movie" value="http://content.screencast.com/users/PJM_LabVIEW/folders/Jing/media/14a79ed5-ef03-4870-94f1-66a1b789dd21/jingswfplayer.swf"></param>'>http://content.screencast.com/users/PJM_LabVIEW/folders/Jing/media/14a79ed5-ef03-4870-94f1-66a1b789dd21/jingswfplayer.swf"></param> <param name="quality" value="high"></param> <param name="bgcolor" value="#FFFFFF"></param> <param name="flashVars" value="thumb=http://content.screencast.com/users/PJM_LabVIEW/folders/Jing/media/14a79ed5-ef03-4870-94f1-66a1b789dd21/FirstFrame.jpg&containerwidth=1068&containerheight=546&loaderstyle=jing&content=http://content.screencast.com/users/PJM_LabVIEW/folders/Jing/media/14a79ed5-ef03-4870-94f1-66a1b789dd21/2009-08-30_1137.swf"></param> <param name="allowFullScreen" value="true"></param> <param name="scale" value="showall"></param> <param name="allowScriptAccess" value="always"></param> <param name="base" value="http://content.screencast.com/users/PJM_LabVIEW/folders/Jing/media/14a79ed5-ef03-4870-94f1-66a1b789dd21/"></param>'>http://content.screencast.com/users/PJM_LabVIEW/folders/Jing/media/14a79ed5-ef03-4870-94f1-66a1b789dd21/"></param> <embed src="http://content.screencast.com/users/PJM_LabVIEW/folders/Jing/media/14a79ed5-ef03-4870-94f1-66a1b789dd21/jingswfplayer.swf" quality="high" bgcolor="#FFFFFF" width="1068" height="546" type="application/x-shockwave-flash" allowScriptAccess="always" flashVars="thumb=http://content.screencast.com/users/PJM_LabVIEW/folders/Jing/media/14a79ed5-ef03-4870-94f1-66a1b789dd21/FirstFrame.jpg&containerwidth=1068&containerheight=546&loaderstyle=jing&content=http://content.screencast.com/users/PJM_LabVIEW/folders/Jing/media/14a79ed5-ef03-4870-94f1-66a1b789dd21/2009-08-30_1137.swf" allowFullScreen="true" base="http://content.screencast.com/users/PJM_LabVIEW/folders/Jing/media/14a79ed5-ef03-4870-94f1-66a1b789dd21/" scale="showall"></embed> </object> Please comment. PJM

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

Hello fellow LAVA members, There has recently been a few Microsoft positions opening up in Redmond, WA for vendor positions. Northwest Contract Services (NWCS) is currently looking for people to fill the following roles, and I don't want anyone to miss these great opportunities: - Labview and SQL Server, tools development experience some experience interfacing to hardware - Mechanical engineer with electronics experience or electrical engineer with mechanical knowledge - Hardware test engineer with software test experience to run interop tests - PM with hardware experience - Optical disk drive engineer - MTE Working for NWCS as a vendor on the Xbox group has been a life-changing experience for me. If you are interested, please respond to this post or PM me your resume and I will directly forward it to people who can give you more information. I am not a recruiter, but have been asked if I knew of any people looking for jobs in these areas. So I figured, why not give back to the community that has helped me out time and time again? LAVA is full of intelligent, talented people. Exactly the kind of people I want working with me on my team. ;-) Here is a brief description of Northwest Contract Services: Northwest Contract Services partners with our customers in the development of significant consumer electronics devices. Our employees work on each project until it is on the marketplace and then move on to other newer projects. Our employees enjoy company paid medical, dental, vision, long term disability and life insurance as well as a 401k program. Joe "orko" Sines

I downloaded the VIP, and VIPM tells me it is 8.6 and up... Is that correct? EDIT: I found an 8.2 version, could the CR version be updated? And while i am at it, some ideas: Show/hide label (and edit) of the case structure Auto-hide and show the dialog when the owning VI is not the top-level BD anymore. Ton