Projets des membres sont la pierre angulaire d'une communauté comme Cemetech. Il génère buzz et apporte beaucoup de nouveaux visiteurs ponctuels lorsque TI, Casio, ou HP libérer un nouveau produit ou un morceau de logiciel, mais pour tous les mois et les années entre les deux, les projets de nos membres soutiennent l'activité du site et de l'intérêt. Bien sûr, nous enseignons aux gens de programmation pour calculatrices et des ordinateurs, mais les utilisateurs sont beaucoup plus passionnés par leurs propres projets de répondre aux questions, à la fin. Et dans une communauté où la majorité des membres sont motivés, intelligents et créatifs, il ya forcément beaucoup plus d'idées de projets que d'heures dans la journée. Pour ma part, j'ai une liste de projets potentiels qui pousse par mois, et un inconfortablement longue liste de projets inachevés. Tout en considérant l'annulation d'un projet en cours et en prenant un autre, j'ai recueilli quelques réflexions que je voulais partager sur les compétences générales pour le choix de vos projets à bon escient, ce que je crains est parfois ignoré dans la communauté calculatrice programmation.

Un des plus gros problèmes que j'ai remarqué sur mes douze ou quatorze ans en tant que membre actif de la communauté des programmeurs est la cueillette des projets qui sont soit au-delà de leurs capacités ou trop grand pour maintenir leur participation. Mes expériences avec les utilisateurs projets débutant mal adaptés à leurs compétences et à la capacité d'attention peut être illustré dans deux anecdotes, bien sûr avec des noms omis de respect. Dans le premier cas, un membre a discuté d'un nouveau système d'exploitation ASM z80 qu'il voulait écrire, exposant de nombreuses fonctionnalités, il voulait comprendre. Moi et d'autres prévenu qu'il devait commencer petit, et après avoir appris qu'il ne connaissait pas avec z80 ASM fondamentaux comme les mathématiques peu, a recommandé qu'il démarre avec un petit projet pour consolider ses capacités et mettre en place à l'effort, de temps et les compétences nécessaires pour écrire un complet OS à partir de zéro. Malheureusement, cette proposition a été reçue comme une attaque plutôt que d'une suggestion amicale, et le projet reste inachevé à ce jour.

Un contre-exemple encourageant peut être trouvée dans un autre utilisateur dans une situation similaire, qui s'est mis à faire un jeu ambitieux. I et d'autres utilisateurs prévenu qu'il devait commencer petit, et en pensant que nous avions des raisons de bienfaisance pour nos recommandations, il a suivi les conseils. Quelques mois plus tard, il a obtenu quelques petits projets, puis a été en mesure de brise à travers le projet plus vaste, à la fin, il s'est retourné et a convenu qu'il n'était pas prêt pour le grand projet. Il a admis qu'il aurait probablement obtenu frustrés et quitter au milieu. Et c'est là que réside le problème: les projets doivent être assez grandiose pour maintenir l'intérêt du programmeur (sans parler de l'intérêt des utilisateurs potentiels au cours du processus de développement), mais ne pas être si compliqué qu'ils ne sont jamais finies.

Et en effet, quand tant de projets amusants traversent votre esprit que vous vous retrouvez avec des listes de croissance de l'avenir et des projets en cours, il est tout aussi essentiel de savoir quand il faut poursuivre et enfin terminer un projet, et quand un projet n'est tout simplement pas la peine plus de temps. Cette dernière catégorie couvre mon client FTP de papier de verre pour CALCnet et potentiellement Tetric B pour la TI-84 Plus Silver Edition C. Dans les deux cas, je suis venu à la réalisation que de continuer à couler effort dans le projet serait une perte de temps. Dans le cas du papier de verre, j'ai terminé assez du programme pour en faire une preuve nette de principe (dans les archives ticalc.org de votre calculatrice et le transfert de programmes entre les calculatrices sur les œuvres sur Internet), mais je reconnais que dans l'âge de omniprésents smartphones et les ordinateurs portables, il ne sera jamais plus une nouveauté. Il ya peut-être une dizaine d'années, il aurait pu être vraiment utile, mais en prenant le temps d'appuyer tous les autres types de fichiers et de compléter le code Python de télécharger des fichiers à partir de Cemetech et ticalc.org serait un effort inutile.

Le projet J'envisage étagères en permanence, Tetric B, tombe dans une catégorie légèrement différente. Bien que cela fonctionne comme il le devrait et pourrait être accomplies dans un autre 5 ou 10 heures de codage TI-Basic, je ne pense pas que cela représente un jeu vraiment amusant, et je serais trop lent lorsque vous avez terminé. Que ce serait frustrant pour les utilisateurs et les amener à penser à moi comme un pauvre codeur, ou être déçu par la TI-84 + CSE dans son ensemble, je pense que je ferais un mauvais service aux utilisateurs de le libérer sous sa forme actuelle. Je pourrais passer plus de temps rognage, l'optimisation, le peignage sur le code source, mais est-ce vraiment une bonne utilisation de mon temps quand je pourrais plutôt essayer une version ASM?

Le message fondamental est qu'il n'y a pas de panacée, ni même un problème évident. Programmation, la construction et le piratage sont des activités amusantes et saines, sûres de vous aider à penser logiquement et aller plus loin dans la vie. Cependant, ces détails tracasseries administratives ne peuvent être ignorés pour vous (et la communauté) heureux. Vous devez être conscient de partir et de ne jamais finir projets, probablement parce que vous avez choisi les projets que vous n'avez pas la capacité, l'accent, ou le temps de finir. Dans le même temps, vous ne devriez pas hésiter à tenter quelque chose que vous n'êtes pas positif que vous pouvez faire, en gardant à l'esprit que vous pouvez toujours tomber plus tard et ne sont pas liés par contrat à la fin de l'entreprise. Quelles expériences avez-vous eu à regarder vous-même et d'autres démarrer, arrêter, tomber, et les projets de finition? Je suis impatient d'entendre le renforcement et le contrepoint de mes expériences dans la communauté de codage de la calculatrice.