Omnimaga
Calculator Community => Casio Calculators => Topic started by: z80man on October 30, 2011, 07:12:41 pm
-
Here is a list of rules and suggestions that I believe those who develop for the Prizm should keep in mind for their apps. Many of these apply to all platforms whether it be other calculators or computers but a few are more targeted at the Prizm.
- Treat the user's calculator with respect. Don't use any code that will put THEIR calculator at risk! Test your programs extensively and remove any holes that could potentially cause a major error. Even if you're not liable for damage, these types of incidents can tear apart communities.
- Applications need to be free. I shouldn't have to even say this one because it rare to happen on a calculator and no good distribution method currently exists. Do note that if you choose to follow this path, few if any people will buy your apps.
- I can't force you to do this, but open source really is a good idea. Source stealing is very rare these days and you really shouldn't care too much if someone borrows a routine. Yes, they should credit you but it's not like your losing any money by their doing so. These are free apps, by the way, so any sharing is only benefiting the common good and remember that our goal is not to please ourselves but to please our users.
- If you choose to follow an open-source approach, keep your code very clean and well commented. Explain what each function does and how the more complicated algorithms work. Additionally, you should provide documentation for the user on how to compile the application or, better yet, provide a shell script and makefile.
- Do everything you can to remove bugs. The best way to find bugs is to try to purposely break your programs to see how they respond to odd conditions. If a program asks a user to enter in how much money they would like to bet, enter a negative number and see what happens and if needed fix the resulting bug or glitch. Another good way to test for bugs is to release alpha and beta versions of your apps because others may find issues you never knew existed.
- Provide a line of communication for your users. Not everyone has an account on Omnimaga or Cemetech, so you need to provide an email, not only so you can provide the occasional help but also so users can report those all-important bugs.
- Your distribution file should include a readme. This should contain usage instructions, compilation directions, and how you can be contacted. Make it easy for the user to find what they're looking for and don't make it too long.
- Value user friendliness over extreme optimization. I'm not condemning optimization—in fact, every program should be extensively optimized—but what I'm warning against is overdoing it. You should always program in extensive exception handlers to prevent the user from breaking your apps. Graphical appearance should also be focused upon. Most users would prefer a sharp UI over an additional frame per second.
- If this is an ongoing project, updates should be regularly released and easily available. Even if an update only fixes a few minor bugs it is still worth it to release.
- Maintain a project topic on a calculator forum. It is recommended that the first post contain all of the most recent updates, screenshots, and information as it is easiest to find in that format. It is also a good idea to have a change log there or in your readme file as it provides a full development history.
- Remember to credit everyone who helped with development of your project. This includes programming, graphics, ideas, music, etc. This should be done in the readme, the project topic, and if possible within the application itself.
- Design your programs to have full forward compatibility and, unless it would hinder application development, full backward compatibility. Don't assume that Casio will never modify the Prizm in the future because chances are that we will see some major changes just like we've seen with every other calculator in history. How you do this is up to you, but one way to do this to make effective use of syscalls as they are pretty well written in stone; a well designed program or routine will also stand the test of time.
- Keep a common user interface. Just like most Windows, Mac, or Linux apps have a similar feel within their own OS we ought to do the same. The best way to keep the look and feel of apps the same is to use either OS or shell calls to draw windows and other UI elements.
- Keep backups of your projects! This cannot be stressed enough. Store updates frequently on multiple computers, on flash drives, online, or in that cloud thing. One thing I recommend is forming an account on GitHub (https://github.com/ (https://github.com/)). You can keep your projects in an online repository and it can also make distribution easier too. Many major open source projects are also stored here including the Linux Kernel which it was originally designed for.
-
z80man, I edited it a bit for better English. Also, since you mentioned GitHub, perhaps an elaboration on version control would be in order?
Personally, I am already aware of these things, but a reminder is always nice :)
-
Nice post, and I agree a lot about the Open source, especially since the Prizm community is so young right. There aren't a lot of apps yet and it's good if new people interested in developing for the Prizm have access to examples, not just documentation.
-
I totally agree with you. There is just a point that needs to be cleared. Some of your points doesn't only apply to the Prizm ;).
So yeah, I should make readmes -.-°
EDIT: I made a readme :w00t:
-
Here is a list of rules and suggestions that I believe those who develop for the Prizm should keep in mind for their apps. Many of these apply to all platforms whether it be other calculators or computers but a few are more targeted at the Prizm.
- Treat the user's calculator with respect. Don't use any code that will put THEIR calculator at risk! Test your programs extensively and remove any holes that could potentially cause a major error. Even if you're not liable for damage, these types of incidents can tear apart communities.
...
- Value user friendliness over extreme optimization. I'm not condemning optimization—in fact, every program should be extensively optimized—but what I'm warning against is overdoing it. You should always program in extensive exception handlers to prevent the user from breaking your apps. Graphical appearance should also be focused upon. Most users would prefer a sharp UI over an additional frame per second.
The first one is especially important in the case of custom flash routines. Don't use them. They have the potential to seriously damage calcs.
Also, the second may not be true for programming utilities like interpreters and emulators. In such reasonably uncommon situations, extreme optimization is often entirely warranted (and lamented if not present).
-
Also, the second may not be true for programming utilities like interpreters and emulators. In such reasonably uncommon situations, extreme optimization is often entirely warranted (and lamented if not present).
Very true but those kind of projects are not very common. Unless a program is pushing the limits of the hardware extreme speed optimization is not necessary. In addition to emulators and interpreters games such as fps's could also fall into this category. One of the main reasons why I put that there is that I find it annoying in some programs when you see a function that is called at most once per second and is optimized to save 10 T states at the cost of 30 additional bytes. That there is just bad programming and all it does is increase the size.
-
Well, that's not really optimization at that point. That's a poor choice of speed optimization over the more sensible size optimization. (You seem to have ignored that programs can also be optimized for size. ;))
-
Most users would prefer a sharp UI over an additional frame per second.
[Citation needed] :-)
I cannot agree with this. I think super nice (and slow) GUI is nice on few first uses. But I prefer faster (and simple / ugly) GUI in the most used application.
Also the optimizing the code is important, the calculator is not fast enough, it is something like Pentium I.
-
Well, that's not really optimization at that point. That's a poor choice of speed optimization over the more sensible size optimization. (You seem to have ignored that programs can also be optimized for size. ;))
that's what I meant there by size optimization. Many people forget the all important size optimization and focus on speed. It also should be noted that on the prizm a size optimization is often also a speed increase too because of the reduced chances of a cache miss