New to AMX programming
Angelo_One
Posts: 9
I've just completed programmer II and I'm looking for best practices I can use to prepare myself for the practical exam. Problem is I'm always being pulled in 8 different directions by my company. So what can I do to keep moving forward so I'm not always playing catch up. Thanks
0
Comments
I went through this where I had to do ER (Emergency Room) style programming on site just to get the job over the line, then of an evening (and on public transport) I developed the code that I wished I was able to write on site. Eventually that structured code became the base of my production code.
Of course you will still have to write ER code on site to patch it all together but at least the base modules and structure are good so the result is as good as it can be given the circumstances.
Always consider the possibility that the current job could be expanded in the future or that you may recycle the current project in another larger project. Consider what you would need to do if there were more touch panels, more zones, more sources, lights, codecs, mics, hvac, security etc.
Ideally adding more of anything would be simply a matter of increasing an array size.
Do all page flips and popups programatically.
Don't make multiple pages when you have several of the same device type, eg make one monitor page and use the same buttons for whatever monitor is selected.
I start all projects by adding a page for every device then once I have successfully controlled everything then the installers are happy and can go to the next job. After that the device control pages become "advanced user" pages and I add in the code to glue it all together.
Also don't get carried away trying to write the ultimate program, I tried and just wrote something too complex that made processors struggle.
Good luck
Programming is an evolving trade - you will look at code written 6 months ago that you believed at the time to be the best thing since sliced bread, only to realize it's not how you'd do it today. That's just the nature of the game, so for a while - you might always feel like you're getting behind.
I don't believe AMX looks for a particular style of programming - just that you're able to complete the many tasks within the practical. If you have any prior programming experience, draw from that with regards to programming practices: comment your code, make sure it's legible, and don't over-complicate things that should be simple. Make sure it works, and make sure the instructor can understand what your coding intentions are.
Also, it can be tough being pulled in many directions, but I've found it is best to be able to wear the many different hats in the industry. Being able to set up a network, hook up a processor, and just be able to understand most or all of the aspects of an install can help greatly.
Good luck with the practical!
When it comes to best practices due to the relatively small size of the AMX community there has been no real authoritative guides produced. However, a few of us put together a Code Format and Commenting Guide for the NetLinx Common Libraries project. This is based loosely on a similar document produced for the Linux kernal and outlines some recommendations to improve readability. AMX also recently published a wicked UI Design Guide [pdf] that collates a lot of what is considered core best practices in the interaction design field. For general langauge agnostic programming practices I'd also recommend The Pragmatic Programmer as a minimum. Jeff Atwood has a good list of further recommended reading.
Oh, and if you're not doing so already start using source control. I highly recommend git.
* if you do actually get a cape please get a photo, I've been trying to convince people at least one person it is 'standard programmer uniform' for years
I'd also like to add that this forum has proven to be a valuable asset to me as a programmer over the years. As was mentioned, we're a relatively small community of people who come from all parts of the globe. While there is good education provided by AMX, there is not a vast cloud of people who create some kind of 'open source' community or anything. There are other venues out there that touch on AMX but this forum is probably the most compreshensive group of programmers in one plae.
We might be a bit grumpy at times but we generally tend to help when we can. A really good practice when posting on this forum for help is to post your code in question. The more info the better. It's not a good idea to ask for a routine to do such-and-so but better to say you're trying such and so and here's the code I've written, what's wrong? We can usually spot stuff pretty fast or offer another approach you may have never considered. I know I learn this way all the time.
So, happy hunting and best of luck. And welcome!
Maybe I'll gety that cape for you
I appreciate the feedback!
The AMX forum is going to be a great tool for my new adventure in programming.
I am SO getting myself a cape now.
http://powercapes.com/custom-superhero-cape
remember to pick the large size, nothing worse than wearing a cape that's too small.
This is what my cape looks like.
Anyway even though I lurk more than anything I've learnt heaps just reading the posts from the regulars. Welcome!
http://hackaday.com/2012/03/27/riding-rockets-and-jets-around-the-frozen-wastes-of-sweden/
I would so wear my cape while riding that, thong and all.
The following may not be so useful for the Programmer practical itself, but I've found the following useful for coping with real life.
Hopefully you have figured out that modules are your friend. I build all my modules in a sand-box environment, and once I'm happy with it I will then add the .tko file to my real-world project. I can think of at least 3 benefits for this approach:
1) Compiling your real-world project is quicker, since the compiler can just link in the .tko file rather than recompiling your module source every time you build the system.
2) If you know your module code works fine in the sand-box environment, the .tko will prevent you from tinkering with your module while on-site in those moments of frustration. (Of course, make sure you have your module source with you on-site in case it really does need fixing/enhancing.)
3) I find it "less risky" to include a .tko module (e.g. for Projector XYZ) across multiple projects. Again, since I can't tinker with the .tko I know that changes in one project are not going to effect other projects. The other benefit is that I know that the exact-same-module works fine in three other projects, so it is less likely to be an issue in the fourth project. This works for me since we have standardised our hardware across the majority of our fleet.
I agree with Kim regarding source control. I use Subversion, since we also use it for other projects here. My subversion tree has a branch for modules, and a branch for projects.
Prior to using a formal source control system, I would make a .zip of the project "as deployed". That is, I would zip up the project and include the date in the .zip filename. This gave me a restore point if I ended up getting so lost with my coding. It also allowed me to replace failed/damaged hardware and be certain that the "new" code was going to be exactly the same as the old code. The prevents new bugs from slipping in as a result of the hardware change. The last thing a customer needs immediately after a hardware failure is a new set of potential "features" (bugs) to learn, since they will not be in the mood for such changes.
Lastly, while persistent variables seem like a great idea, I prefer to think of them as a band-aid solution. Yes, they work well and do what they claim to do, but there are two real situations where I have regretted using them:
1) The timekeeper battery goes flat after a few years. Once this happens and you have a subsequent power failure, all your persistent variable values are lost.
2) In the event of hardware failure, you may not be able to extract a copy of the persistent variables to put onto the new hardware.
I prefer to load all my "persistence" from a file at boot time, or at run-time on demand. The values are loaded into volatile variables, and I can keep a copy of the file offsite for restoring to new hardware, etc. (This is great if you need to duplicate a deployment on your test environment.) When I started this approach I used the variable_to_xml function, but after several years I put a little more effort into parsing a ".ini"-like file with key:value pairs. This gives me much more flexibility and allows me to store different keys in the .ini file, depending on what the specific room requires. The key:values are accessed via a module as follows. When changes occur I have a 3 second delay (to allow for multiple bursts of change), then save the changes to the file.
Yours,
Roger McLean
Swinburne University
Much thanks Annuello!
I have been meaning to post a reply to this thread for the last couple of days, but keep getting derailed half way through and not remembering to finish. At this point I'll mostly just be repeating things that others have said, but what the heck. Hopefully this time I actually get it posted. <fingers crossed>
I'll second this big time. Last year I got to do a major upgrade on what was the second large system I ever programmed. The whole time I was working on it I was running into stuff that made me think, "Wow I am so much better at programming now" :cool:
I also just want to join the crowd recommending that you use some kind of source control system. The few systems I have that predate my discovery of source control (and in most cases predate my being a programmer) can get confusing as hell because of all the different copies I have from every time an update was made. Also, nothing is more frustrating than making a change that breaks something at 16:00 and realizing you just saved over your copy of the previously working code.
I currently use Subversion, but if I were starting from scratch I'd pick either git or mercurial as having all your previous versions available and being able to make commits without an internet connection sounds very nice.
And finally, as annuello said, modules are your friend. The more code you can easily reuse, the less time you have to spend tracking down pesky logic errors when you're trying to commission a system, and the fewer calls you'll get about bugs. As an added bonus, they make programming much faster
I pack all my device communications in modules, and also build interface modules for devices that have interfaces that are the same from system to system (like video codecs and dvd players).
Again, congratulations and welcome to the club
-Ryan