Idea for handling your project code in 2017
by, 01-01-2017 at 17:10 (502 Views)
Your code. Your creation. Your history of thrill, discovery, ingenious solutions and proud publishing.
Let me remind you of how we shared the code in the past, and what could be the possible direction for 2017.
For years, we got used to a simple system. When we developed piece of code worth sharing or showcasing, we pasted it as forum post, or added it as attachement.
This approach worked, and over years we learned some rules - to stick the latest version to the first post of the thread, along with instructions how to use it.
This approach works, but can be fragile at time. Why? What are the risks?
Problems of the current approach
Sometimes, you would like to take the published version and revert some changes - but you can't, because you erased the original on the hard drive.
And even if you found the backups, there is ton of them and you don't know the differences between different versions.
Sometimes, you would like to step up and create project with multiple collaborators. Fixed ZIP file is not the most reliable choice.
Sometimes, you create a project which could use an extensive documentation, laid along with the code.
I believe all of these issues can be solved by publishing the code into some form of versioning system.
There are many solutions, but I found one especially useful in the last two years - GitHub.
Enter the GitHub
GitHub is one of the services built around Git. Not helping? Git is low level tool for versioning management, it has a very powerful commandline interface, and a well crafted documentation available.
GitHub makes the work with Git simpler by providing both free online hosting for public code and Windows GUI client, which hides the complexity from you.
GitHub client stores every change you do on your code - you just snapshot the code by so called commiting from time to time, and you can both view the changes and revert to them and back at any time later.
GitHub also makes it easy to collaborate - your helpers can create branches, where they can experiment with the original code base.
Then they can propose a change to be integrated to the main branch, usually called master by making so called pull request.
This means you can stay in control of the development and integrate only changes you wish to happen.
Last but not least - you can accompany the code by a Wiki page, which is one of the many extra features the service offers, for free.
The whole code is organised in so called repository, which can be further cloned and adjusted by your collaborators. If you allow them to.
I used GitHub for many personal and professional projects over the years. You can have a look for example at Log007, a very simplistic logger for thinBasic scripts.
You can see the project consists of few files:
- README.md, which is GitHub standard way to give users information about the project
- .gitattributes, which is Git configuration file, telling that we want to preserve Windows line endings in the projects
- log007.tbasicu, which is the actual code unit, shared with the community
- ...and unitTests directory, which contains some tests verifying the functionality
You can review the changes I did over time by looking at commits.
You can also review the documentation on attached Wiki, and also download various Releases for those, who don't want to use Git/GitHub to obtain the code.
To stay connected with our community here, I created a related forum post and I encourage to do so for your projects as well.
If I got you interested, you may consider starting your first thinBasic GitHub project. I created a template for you, in our thinBasic repository.
All you need to do now is:
- go to GitHub.com and create an account
- download the desktop client application
- fork the template for thinBasic GitHub project by clicking on fork button, once logged in
By doing so, you did the first bold step in becoming a modern thinBasic coder, with his code under complete control.
Should you have any questions, just let me know in the comments.