ShaunR

Maintainable code is not really quantifiable-it is a subjective assessment. All code is maintainable, it's just how much effort it requires. Even a re-factor (euphemism for a re-write) is a form of maintenance. Good coding practice and style can go along way towards making the life of a programmer easier but, the crux of the matter is that it can look as pretty as you like and you could have filled out every description and hint but if it doesn't work; you won;t get paid and you won't be asked to come back. . Therefore it cannot form the basis of a performance or coding metric for the purpose of quotation or deliverable. It's a bit like "future-proofing" in that sense. Additionally, only programmers care about neatness because they are the ones that will be required to maintain it. A project manager just wants it to work and it's your (my) job to make sure it does even if the wires are out by a pixel or two. So I like the grading scheme here because it will be a good indicator that they can write working code under time pressure (like the day before delivery ).. programmer [proh-gram-er] : noun 1.a person who converts caffeine into computer programs.

Good news.Rolfs HTTP library does support Proxies! (without authentication). The parser doesn't include the HOST in the header, though, so you should add that (trivial change). Servers have tightened up their security in recent years and the Host field is mandatory on most servers nowadays...

No. What you are describing is merely prepending a sub domain name. Whilst sometimes people put a proxy on a sub domain, it's not a requirement. Besides, you may need to authenticate with the proxy. Under normal conditions, the GET request URI is usually a relative path (doesn't have to be but is usually the case) and the HOST field of the HTTP header contains the domain of the target page. It's is slightly different with a Proxy. The GET URI is the full URI of the target page (including the http:// and the domain name of the target page). The HOST field is the domain name of the proxy server and you connect to the proxy server, not the server that has the page. A proxy may also require authentication and these parameters are also sent in the HTTP header fields (see section 2). I don't believe any of the LabVIEW web oriented VIs support Forwarding Proxies (the sort I think you are describing) out of the box. I may be wrong and they added them in later versions, but I haven't come across any. You might try Rolfs HTTP VIs, I can't remember off-hand if they support proxies and the OpenG site is down ATM so can't check, Apart from that I expect you will have to hand craft these headers and handle the responses the old fashioned way (and you will be stuffed if it is SSL/TLS).

All of them want working code, on-time and on budget. Simples.

Depends on your approach, I suppose. Or, more specifically, how much time you have. I haven't met a customer yet that would say yes to me billing for more time to make the diagrams look better or fill in all the VI descriptions/labels. I tend to throw stuff at the diagram, get it working, then make it look pretty. In fact, when faced with a particularly knarly problem, I will go around and fill in descriptions, labels and make icons as a distraction. It fits with an iterative development better as you can make it look better with each iteration, as long as it works. Often, as more features are added to diagrams, they need re-prettifying as the feature list increases so making it pretty off the bat, is a bit pointless. But here we are talking about an exam which is designed to be time stressed and given that the purpose is to certify coding competence, not the examinees graphic design skills or obsessive/compulsive tendencies; I think this emphasis of marking is more fitting. If you have time at the end of the exam to make it easier to read for the examiners, great, but if it's that bad they can press THE button. However, working code is a better yard-stick for coding competence and debugging capabilities in a time constrained environment, IMO (at least for a CLED), and that's what employers want. The Architect cert is probably where how pretty it looks is more relevant (more a test of communication than CLED), once you've proved you can write the code first.. But what do I know! I've no certifications at all

Depends what you mean by "easy". Write a pascal script to check in the registry for the Run-Time and if it doesn't exist invoke the run-time installer. If you have the download plugin, you can even get it to go and fetch the installer from NI, then run it.

A much better grading scheme IMO. Employers pay you for functioning code, not whether you fill out labels or descriptions. It's only really a necessity for toolkit developers.

......and you stopped showing the top 10 like count on the main page the day after I got to #2

The issue isn't so much accessing SQLite on network drives; I's concurrency. I can quite happily read and and write to my NAS boxes, but woe betide if you try and share the DB amongst clients. Just for giggles, I ran the Speed example and pointed it to my NAS box (over a wifi connection) and it achieved about 0.5 secs to insert and read 10,000 records. .

There is the possibility that data won't be written to the DB when using PRAGMA SYNCHRONOUS=OFF,on a network share but if that is acceptable then, you should also set the PRAGMA journal_mode = PERSIST The default is DELETE and this severely hinders performance on network drives and increases the possibility of collisions and locking errors.

Then why not have the server write to the CSV file (or whatever) then just import it to a local database for use? It'll be a one hit performance to retrieve then full SQLite performance whilst in use.

This is what the SQLite peeps have to say. They are really talking about a single client, however and you will find it impossible (I think-never tried) to create a shared locking mechanism between two machines. You might as well use a proper client/server DB. There is a compile time option where you can choose the locking mechanism (file based may work better), but you would have to compile it yourself.

The big benefit for developers that I see here is that it may highlight some of the source control issues that we have suffered for many years. It may prompt changes in the core so that we can use these powerful tools (like github) much more effectively. I dare say that once you have 20 branches all pushing their changes, the nightmare of merging, cross-linking and phantom recompiles might be laid to rest once and for all That alone should be enough of an incentive to participate, if only because pushing changes will cause such havoc for the people merging the Master that they have to do something before they tear [the rest of] their hair out

Bugger!

.I have been bitten hard on all the LabVIEW installers (most recently by JKIs). Whilst I love Inno Setip and have used it for many years, I need a x-platform one and they are a bit few and far between (how I wish Inno was x-platform!!!!). Now I'm dissatisfied with all the "preferred" options I'm checking out InstallJammer to see if it is a better solution for my needs.

I have to echo Rolf here. I have never found any source control software to be .adequate for LabVIEW. I just treat them all as backup and restore systems. When working with multiple developers I usually break the project into multiple sub-projects that each developer can own, so to speak. It's just a less granular way of what Rolf is describing. My advice is just avoid merging in LabVIEW altogether.You'll live longer .

I think you will need to scale back your expectations as to what you will be able to achieve for the software aspect. How much time do you have left? I'm guessing that you have spent most of your PHD time creating the hardware and now it's "just a little bit of software to make it work" Remote communications (especially for hardware) is not a trivial subject but you can get an idea of how you might tackle it (and the complexity) from XML-RPC Server for LabVIEW or Dispatcher in the Code Repository. There are also examples shipped with LabVIEW to show the basics of client/server communications. That is before we get to actually controlling the hardware. Personally. If you have experience of text based programming (did you write the firmware?) and are on Linux (which I suspect from the phrasing of the question) then I would use Python.

You don't.

Well. You you won't be able to use Google Maps without a lot more experience with web applications and JavaScript. This is the easy way, but you will have difficulty updating the map, online, programmatically from you application.. Web Rainfall.vi You will have to download and install Google Earth instead of using Google Maps and use the library previously linked (if it works) to add your KML to the Google Earth interface.

You can use that software if you are using Google Earth (never used it, so don't know if it works or not). But if you are using Google Maps from a web browser as an activeX (or.NET) component in LabVIEW it's even easier. Log in to Google Maps with your google account. Click on My Places and that will take you to a page where you can create maps. Create a new map, add your KML overlay file and then just point your LabvIEW thing (browser?) to that map.

Not sure what you are asking here, but KML has the ability to define the colour of a polygon (or line). The polygon is defined by map coordinates Here's a simple example that I found by Googling that enables you to turn on and off a coloured KML overlay.

LabVIEW is just the host. You need to create a KML file then get Google Maps to load it.

"the less she knew about a thing, the more she wanted to try it." I can see why

Well done Jim. You've just closed down a boutique in France

I think it will take several years for anyone to overtake Crelf on the post leader board, even if they post multiple times every day