Open Source AMX Projects
PhreaK
Posts: 966
This is a continuation of the derailment initiated here.
I guess I'm probably in a different situation to most of the people on here which makes my opinions differ somewhat. I work for government so I'm paid to create, maintain and continuously improve systems, rather than develop them in a way in which time spent can be most effectively monetized (this isn't an attack on anyone, just a major difference between not-for-profit and commercial operations).
I'm currently in the process of attempting to get approval for all code produced for our systems to be open sourced. The way I view it is that we could continue to keep our projects closed source and keep developing in our own happy world, however as we have no intention (or ability) to ever attempt to sell these system, or their components. Alternatively, if we were to open source our work any code created could be freely utilised by anyone willing to poke at it, and in return we stand to gain from having another set of eyes going over it, someone who may have been completely detached from the original development and is not biased by early preconceptions or 'emotionally attached' to any components of the system (most people tend not to throw out code they've slaved over, most developers will try and modify, refactor and manipulate, even when a re-write of a particular area of functionality may be by far the more effecient solution). Again, my justification for this approach here.
Additionally, if any components of our system were widely distributed it stands to significantly reduce any training and adaption times of any additional programmers already familiar with those components who are brought onto the team in the future, or subcontracted to develop any system components.
As far as advantages for those who do rely on monetizing their code, why not sell it as a feature to your customers. There has been multiple rounds of research showing that customers are more likely to become loyal, happy, and well paying if they are not threatened by predatory vendor lock in - i.e. we built your system so our company, and only our company are you sole source for support, modifications and bug fixes (there are some exceptions to this, such as when you reach a critical mass of market share etc). Think about it, would you buy a car if it's hood was sealed, and the only place that could service it, without having to build you a complete new car, was the dealer? People like choice, and if you produce good work you have nothing to worry about.
Anyway, to return form my derailment of a derailment - the 'Open Source RMS Replacement' that is being talking about. I wouldn't call it an RMS replacement. RMS does a lot (some of which I'm not sure why), however it is also lacking in a lot of areas. I get the feeling that what a lot of people want is something that does purely monitoring (no scheduling, messaging, meeting management etc). Something that can provide active system health monitoring, usage statistics and data for planning maintenance schedules. What could quite easily be built by the community (even if that is only initially 2 - 3 people) is a lightweight data logging framework. After all, we build custom systems, we don't want the tools we use to restrict us, or our design patterns. Once the data has ben logged there are already a plethora of data analysis and visualization tools, or the option of building customized solutions for that which meet the project requirements.
Anyway, let the discussion continue...
I should also point out these are my views and not that of my employer. We happily use RMS and will continue to do so, especially considering the time and money we have invested in it's deployment.
I guess I'm probably in a different situation to most of the people on here which makes my opinions differ somewhat. I work for government so I'm paid to create, maintain and continuously improve systems, rather than develop them in a way in which time spent can be most effectively monetized (this isn't an attack on anyone, just a major difference between not-for-profit and commercial operations).
I'm currently in the process of attempting to get approval for all code produced for our systems to be open sourced. The way I view it is that we could continue to keep our projects closed source and keep developing in our own happy world, however as we have no intention (or ability) to ever attempt to sell these system, or their components. Alternatively, if we were to open source our work any code created could be freely utilised by anyone willing to poke at it, and in return we stand to gain from having another set of eyes going over it, someone who may have been completely detached from the original development and is not biased by early preconceptions or 'emotionally attached' to any components of the system (most people tend not to throw out code they've slaved over, most developers will try and modify, refactor and manipulate, even when a re-write of a particular area of functionality may be by far the more effecient solution). Again, my justification for this approach here.
Additionally, if any components of our system were widely distributed it stands to significantly reduce any training and adaption times of any additional programmers already familiar with those components who are brought onto the team in the future, or subcontracted to develop any system components.
As far as advantages for those who do rely on monetizing their code, why not sell it as a feature to your customers. There has been multiple rounds of research showing that customers are more likely to become loyal, happy, and well paying if they are not threatened by predatory vendor lock in - i.e. we built your system so our company, and only our company are you sole source for support, modifications and bug fixes (there are some exceptions to this, such as when you reach a critical mass of market share etc). Think about it, would you buy a car if it's hood was sealed, and the only place that could service it, without having to build you a complete new car, was the dealer? People like choice, and if you produce good work you have nothing to worry about.
Anyway, to return form my derailment of a derailment - the 'Open Source RMS Replacement' that is being talking about. I wouldn't call it an RMS replacement. RMS does a lot (some of which I'm not sure why), however it is also lacking in a lot of areas. I get the feeling that what a lot of people want is something that does purely monitoring (no scheduling, messaging, meeting management etc). Something that can provide active system health monitoring, usage statistics and data for planning maintenance schedules. What could quite easily be built by the community (even if that is only initially 2 - 3 people) is a lightweight data logging framework. After all, we build custom systems, we don't want the tools we use to restrict us, or our design patterns. Once the data has ben logged there are already a plethora of data analysis and visualization tools, or the option of building customized solutions for that which meet the project requirements.
Anyway, let the discussion continue...
I should also point out these are my views and not that of my employer. We happily use RMS and will continue to do so, especially considering the time and money we have invested in it's deployment.
0
Comments
I actually thought about going down this road when I was hired for my current position. We quickly decided that it was not pragmatic and agreed to dismiss RMS in favor of switching over to Extron's license free monitoring software, GVE. The UI is much more user-friendly and the page loads are ridiculously faster. I spent a couple of days developing a single include file for getting all of the AMX systems to report to the server. All devices use my own protocol to report status to a virtual dev which in turn interprets the data, stores it to structure and updates the server. I back up all messages in an array, also. When I get time after this summer's project season is over, I plan on backing everything up to XML files on the master, maybe emailing them and saving for archival purposes. GVE's database is pretty stout as well. The reporting capabilities have been very helpful thus far. That being said, their last patch broke a lot of important things. This is not a completely perfect product, but one that they are committed to constantly develop and upgrade. They have also received a ton of feature requests from me, as well.
The point I think this makes is that there may be some other reasonable alternatives. RMS was pretty bloated and with at least 6 different programmers doing the work, it never worked right, period. Most of the blame is not the fault of AMX, to be fair. Most of it involved the fact that the previous manager of our dept left, leaving no one to grab the reigns. The scope was too large to deal with, so a change had to be made. The current solution is far more manageable and streamlined.
Yay. If it's AMX stuff, there aren't many eyes that would look at it, but those that do would be more likely to say something...maybe. Perhaps more so than the typical project, anyway.
And the most important part: I won't work for a company that doesn't at least give the opportunity for the customer to have their code. I've met a number of customers, who came from both short and long term relationships (or lack thereof) with other integrators, who had closed code systems and no way to get the code. None were happy. I've rewritten their systems and some still weren't happy, usually because they just paid for something to be done for the second time just so they could do something easy like turn a TV on. (Usually it wasn't the money so much as the time, ...rich people =/) However, all were happy to know that I'd give them a copy of the code when I was done. My personal experience is a bit skewed as I've always given code if I could, but our customers always seemed happy.
As stated in my previous post, this is something that we could use, but not something we need. I personally would love something like this, though, and certainly wouldn't mind starting on it...but don't really feel like doing it for free. I write enough code at work and with my hobbies to do something that only interests me a little compared to other projects and hobbies.
Maybe if there was a pledge or a pool for some kind of thing like this, that'd light a fire under my ***...but I don't think enough people want it or care about OSS for it, either. If I was in your position and was being paid for it, I'd get started on it
That's the problem. At work we are very much heavy RMS users so there is no need to reinvent the wheel for our situation, especially when it's a very expensive wheel.
However, that being said I am going to have the need for something along these lines for my home system (when I finially have time to build it properly).
As far as the pool / pledge system in my past experience they tend to work a lot better once a functional product is available, that way those who are willing can pledge $x for y feature to be implimented and have a say it development direction by providing financial backing, or alternatively if they have the time / skill contribute to the project themselves. If there is a couple of developers who all want a similar product at a similar time and you're going to build be building it anyway by open sourcing it you stand to drasticly reduce the development time and increase flexibilty. At that point if people want to take in seperate directions, customise it to a specific niche etc then just go your seperate way, nothing is lost. You can still sell the functionality to your clients and you've invested less time to receive the same financial gain.
I did set up a publicly accessible subversion repository at http://anonymous:anonymous@svn.trueserve.org/amxstuff/ - I'll be adding some of the stuff I've done recently, like a 7-day forecast module, touchpanel interface and Color Viewstat interface - yeah, I know they give you three years of i-Weather, but mine (via CDYNE) doesn't expire, doesn't cost money, and doesn't require Duet.
Then there is the single, dedicated open source project or product that has a set of requirements and goals and the group as a whole participates in its development. We all know the long list of successful applications that have followed this path.
I think Kim (Phreak) is suggesting this for a product that monitors Netlinx systems in a fashion similar to RMS, but on a much smaller, simpler scale. I think that would be quite an undertaking, but I would suggest going to an open source site, like Sourceforge (sf.net), create a project, set up some goals and initial tasks/milestones, invite others and see where it goes. You only need approval from SForge to create the project. Anything after that is up to the administrator and/or the group as a whole that is part of the development.
As they say, if you build it, they will come. In this case, if the goals are sound, I am sure that others will contribute. I don't know that I will personally as I am generally buried up to my eyeballs in my own programming.
Just my thoughts.
Sheldon Samuels
SchoolView Technologies
I will contribute with this if I can as I don't mind spending a little free time on these kind of things. In the end you'll still get paid to implement it so I don't see an issue there either.
Also true I'd like to help you with the projects you have in your repo, could you make me an account? My mail is jordevorstenbosch (at) gmail (dot) com (i know these are private forums, but bots may be lurking
i. Also agree that RMS is simply too large/bloated to be used in other projects.
@Kim you'll be paid?! Damn
Kudos,
Jorde
Not for this one unfortunately. Like I said we're already up and going with an RMS deployment at work. If I'm working on this project it's on my own time for my home system.
http://groups.google.com/group/netlinx-common-libraries
As I get the time I'll be trying to post up some code formatting and commenting style guides to make sure everything keeps looking nice and remains readable on theses projects. Again, if anyone would like to contribute please feel free to jump in.
The groups also serves as a mailing list for any project announcements - new versions, bugs etc, so even if you aren't interested in contributing to the documentation join up to the group and it'll shoot you an email whenever there's some new code for you to use and abuse.
Cheers.
Some pointers here (this may alienate most NetLinx devs): http://www.linuxjournal.com/article/5780
Should I start migrating stuff like this to the group?
Indentation All tabs are eight characters and will be the <TAB> character. This makes locating where different blocks of code start and end easier. If you find that your code is indented too deeply, with more than three levels of indentation that cause the code to shift to the right of the screen too far, then you should fix this. Placing Braces The original authors of UNIX placed their braces with the opening brace last on the line, and the closing brace first on the line: if (x is true) { we do y } Therefore, the Linux kernel uses this style. The exceptions to this rule are functions, which have the opening brace at the beginning of the line: int function(int x) { }By some fortune of luck that's the indentation I use but I simply can not use braces like this. Most guys here do, do it like that but I find it unreadable. I like matching braces over each other and indented with the first line of code and I completely understand I'm an odd ball but that's what happens when you devolope a writing style with out outside influences and rules. You tend to do things that make sense to and for yourself. Any time I touch code like this I have to re-format any section I touch otherwise it will drive me crazy. I guess being anal w/ OCD has its draw backs but since I live in my own little bubble I'm happy to continue doing it wrong. Ya see in my world it's all you guys that are screwed up.Why not use the "rules" or "suggestions" from AMX? I'm sure a simple email to the training department would easily set it straight. Or even an email to Pro Services - heck, they write code for clients and I know they have certain rules. They just don't let their programmers go buck-nutty and just get it done.
Eight characters for a tab? That would be very difficult to read. In Netlinx I use two and in most other languages 4, but never 8.
Paul
I also use 3 22" monitors from left to right so I do have plenty of real estate and the larger indents just make things clearer and less jumbled up. I can't take it when things are cluttered and bunched up. I like white space!
Some of the "rules" and "suggestions" by AMX are completely wrong, and others unnecessary...take a look at my sig, for instance. (If you want me to drone on as to _why_ this is wrong, I'll do that too, but I'll spare you and suggest Google =])
Some things, like braces placement, indent style, and spaces between functions and parameters, are usually learned early on and stick with a developer as a preference, and are usually tied to the language first learned or first widely used. Most AMX code I've written is written in CAPS LOCK (except for the retarded hungarian type specifier, in lowercase) and with allman or whitesmiths braces, and that's likely because people from the AV industry learn to write code from vendor-provided training and existing examples which look like this more often than programmers come into the AV industry. Here's some more info regarding indent styles and brace placement: http://en.wikipedia.org/wiki/Indent_style
(Unlike vining, I find allman or (especially) whitesmiths braces much harder to read than unix-style braces. They waste too many vertical lines, leaving less code on the screen for me to read.)
Some of the worst code (readability wise) I've seen has been AMX-authored code, code on these forums, and S+ stuff written by actual Cres employees. Seen some good stuff on that side, too - depends on who writes it. PhreaK's code is quite easy to read, although some variable names are unnecessarily long, but it's minor. There's something to be said about simplicity that just usually isn't thought about in this realm of development.
I'm not sure. As it is, training feeds misinformation to people being trained (such as how 'include' or '#include' works) and fights when this misinformation is refuted. It doesn't help either that training teaches people to write code who've never written code before in CAPS LOCK. That's some 1970s hacker preference that I've only seen still living in this market of software development, and it doesn't help to have to read it now that these people are writing it when I have to take over their work.
That's the one main thing where I deviate from kernel-style guidelines - I personally write at 4 space/tab, <TAB> only, at 120 character width. Some projects I write at 5 space/tab but not many.
Then I can see that you probably won't be helping with any distributed development tasks. With these, you commonly _have_ to change to conform to the standards previously set by the group. Sometimes I don't like to either but that's the rules
Why force humans to obey rules when we have computers to do that? Write code any way you want and then display it any way you want. Then everyone's happy (except the computer that now has to spend cycles doing something it previously didn't have to do. Thankfully we are still its master....for now).
Paul
The reason for development guidelines and rules is so other humans can understand what you are doing and can contribute. The human interface aspect - the code itself and likely the result of the code - can't be ignored and, with the vast majority of projects, is the most important part to continued success of the project. If software is unmaintanable, who will maintain it?
Society has rules, and (usually) so do communal programming projects. If you want to write code for yourself, great, do it any way you want. If you want it to be maintainable by others, then write it in a standard way, that being the guidelines set by the community or team you are joining. (Most guidelines and rules in the OSS world are similar, except for GNU project stuff, which is Stallman-esque and different from everywhere else...)
(Protip: writing unmaintainable code in the software industry will not only make your job hell, it'll also make you likely not have a job. Sadly, integration isn't considered a software industry by any stretch.)
You seem to be confusing software engineering with style guidelines. They are different things. Style can be manipulated with software so that everyone can code in the style they prefer, and view it in any style they prefer. Poor software design leading to maintenance problems is much more difficult to fix. Surely you are not claiming that using a different tab size makes code unmaintainable.
Considered by whom?
Paul
The problem we stand to face here is that there are no code formatting utilities (that I'm aware of) currently available for NetLinx (again, if someone would like to write an eclipse plugin I offer my firstborn). As a long shot, has anyone tried running any NetLinx code through a C or java formatter and seeing what happens?
Failing that, it is going to be important to establish a standardised code style guide for general layout, library architecture and, perhaps most importantly, commenting and documentation. The nice thing about our situation is we have the advantage of starting with a blank slate and not having a mass of legacy issues to deal with. That being said, unless we establish this guide in the short term it is likely to bite us in the arse in the future with said legacy issues.
Before we start a 'my coding style is better than yours' flame war it is important to recognise that none of us are likely to be completely happy with the result, but if we can start putting together some base guidelines and open it up for comment we can work towards selecting the least ugly child.
Like true said code, especially in collaborative projects, must above anything else be easily readable by other humans. Anything contributed is going to be read many more times than it is written.
Exactly. Even then, I prefer writing in the target style rather than using an automated tool, so...
And we do need a target style to write to anyway, don't we?
Surely someone can write a converter or plugin, but it's something I don't care much for
The hardware companies, vendors, and dealers. We sell solutions, not software (well, most of us).
I see this whole thing as an opportunity for you and others to make a little group, comprised of your own rules for egotistical purposes? Instead of keeping up with AMX's standards (even though you call them wrong), this group you're going to form will try to teach all the new programmers that go through AMX programming (by AMX mind you) to deviate from the standards of AMX. Call me old school (compared to you guys), but as much as you hate playing with the coding style I use, we (maybe the majority of coders) probably hate dealing with your style just as much.
I will again suggest using AMX's standards since that is the official authority of the language. I would be happy to branch off and use a different set of "rules" if you insist on using something other than the true standard - something that I will be working on getting *from* AMX since you have very little confidence in the people who run the training department or even Professional Services.
I think one of the major issues with the coding style used in the AMX training is the lack of any documentation standard as well as the lack of guidelines for helping avoid conflicting namespaces.
Please don't get the impression anyone is trying to do this simply for an ego boost. The goal behind establishing these guidelines is so that people don't spend 3 hours reformatting the libraries to their standard before making any changes, or even worse, the libraries start using a combination of standards and layout / naming guidelines.
PhreaK has it right - people won't really be happy with everything in a programming guideline. Most aren't used to following one. But for ease of maintainability and readability for something that's committed to by (hopefully) a substantial group of people, it is a necessity. Looks like another project could be hacking a beautifier into NS3...
Also, I don't think "conflicting namespaces" is so much of an issue because there aren't any (or one depending on how you count)
jjames, you have it right too, with some exceptions. AMX doesn't have programming standards so much as general practices, and in the context of nearly any other procedural language used today, I do believe they have it absolutely wrong. It doesn't help that AMX isn't consistent in said practices. And yes, I have no confidence in the people who run the training department and feel bad for those who are subjected to programmer training. (I do admit, they have a hard job, but in the end they go about it wrong.) I also see that you may have some animosity towards me, and I can understand it, but try not to take it so personally. I'm just voicing my opinion and not attacking anyone. If you'd like to know why I have this opinion or would like to discuss this further, please start another thread or send a PM and we can discuss it.
I do invite you (and anyone else interested) to commit anything you want to share out in the open to my repository, in whatever programming style you wish, if you wish to do so. I don't know how interested you are in actually assisting in development, though. If so, send me a PM and I'll set you up an account.
As for the discussions that have been going on, I HIGHLY recommend watching these two videos on the open source philosophy and open source projects.
Google I/O 2008 - Open Source is Magic:
http://www.youtube.com/watch?v=hmZyyBVbkOQ
Google I/O 2008 - Open Source Projects and Poisonous People:
http://www.youtube.com/watch?v=-F-3E8pyjFo
Jeff
And like said before coding style is part of the software engineering process. If you don't believe me I can recommend a few books on software engineering that'll make you see things in a different light.
Please do.
Paul
I will be adding the files that I have as I have time this week. I am a noob when it comes to really working with others using subversion, so please feel free to let me know what can be improved on my end to make things smoother. I have started making the switch to Linux Kernel formatting, so feel free to point out my mistakes and I will try to correct the habit.
I am going to use this project as my foray into the open-source arena. I will be as forth-coming as possible and I will try my best to divulge a fully functioning product. I am withholding the particular security routines I am using as I have not had time to look into implementing code that does not rely on some amount of secrecy to function. I am taking a financial risk in releasing this code for free in the hopes that together we can make a product that is better for the end users, ready quicker, and more reliable than something I can code by myself.
Jeff
So it looks as though some form of linux kernel inspired coding style is holding the most traction with people. I'll try and start piecing together a wiki this week using that as a base so that we can mutate it to best suite the abilities (/inabilities?
On a side note, be very careful relying on secrecy of the algorithm for any security or crytptography routines.
Paul, books I can recommend.
Code Complete
Coder to Developer
Developer to Designer
A series of books:
Pattern Oriented Software Architecture System Patterns - Volume 1
Pattern Oriented Software Architecture System Patterns - Volume 2
Pattern Oriented Software Architecture System Patterns - Volume 3
Pattern Oriented Software Architecture System Patterns - Volume 4
Pattern Oriented Software Architecture System Patterns - Volume 5
Well of course you need a lot of time to read all that, but there's far more I can recommend.
For a general impression of what software engineering is you could read this wikipedia article:
http://en.wikipedia.org/wiki/Software_engineering
Be sure to check out the sub-disciplines section
Lemme know when you need more reading, as I know some books that go far more in-depth on certain subjects. (A lot of OO principals apply though).
If the plan is to host this on your own servers you might want to look at xampp. It's pre-configured bundle of apache, php, MySQL and apparently now has Perl. It takes the pain out of the setup.
http://www.apachefriends.org/en/xampp.html