12-25-2022, 12:33 AM
I wanted to document for people, the process in which an application gets from point A to point Z. Transparency to the community, is always good too. Other than Step 1 from below, this process is exactly the same for any changes to an existing application to.
1. The formulation of the idea:
The first step is the idea, the first thought. Usually this stems from seeing something that people are doing and making that process easier with software. It could be a Forum or Social Media post about an issue someone has. It could be an idea from an existing piece of software that is either clunky, of poor UI (user interface) design, bad implementation, or a combination of some or all of these.
2. Time to plan:
This usually takes the form of a piece of paper that I start to lay out the UI and ideas about how people will use this software. I like to write and draw, and in this day and age, that activity alone is rare and has been mostly replaced by technology.
3. Write the code:
I'm not big into IDE's (integrated development environment) which is just a fancy way of saying the editor in which we write code. I think for me, it's a visual thing. Syntax highlighting is too distracting. So I use a plain text editor like Mousepad. IDE's also can make people lazy. I think it's a good idea to do your own indentation as an example and to be familiar with best practice in programming, rather to rely on any type of automation.
4. Test the code:
I don't use a debugger. Shock, horror! For me, programming and fixing code is one of the fun parts. Ambiguity has a certain attraction. The challenge of figuring out why something doesn't work, draws you closer to a greater understanding of the how and the why, and I like that.
5. The Test drive:
Do I like the clicky? How does the UI function, do I need to tweak it? Let's get a friend to test drive it. Let's test it on more than one machine, including hardware and in a VM.
6. Ready for mass production?
Test, test and then test again. We're ready for release. But not before we upload the new package to a test repository (a new Linux Lite implementation and the inspiration behind this thread and the recent Lite Patch issue), then perform an update via both the command line and Install Updates.
7. All's well that ends well:
Everything works as we expect it to. Maybe some Social Media announcements, but generally I'll just upload the new package to the main Linux Lite repository for everyone to download via Install Updates.
The work flow:
IDEA > PLAN > WRITE THE CODE > TEST THE CODE > TEST DRIVE THE 'FINISHED' APPLICATION > WRITE THE CHANGELOG > PACKAGE THE APPLICATION > UPLOAD THE PACKAGE TO A TEST REPOSITORY > TEST THE UPDATE FROM THE TEST REPOSITORY > RELEASE TO MAIN LINUX LITE REPOSITORY > REACT QUICKLY TO ANY OVERSIGHT
1. The formulation of the idea:
The first step is the idea, the first thought. Usually this stems from seeing something that people are doing and making that process easier with software. It could be a Forum or Social Media post about an issue someone has. It could be an idea from an existing piece of software that is either clunky, of poor UI (user interface) design, bad implementation, or a combination of some or all of these.
2. Time to plan:
This usually takes the form of a piece of paper that I start to lay out the UI and ideas about how people will use this software. I like to write and draw, and in this day and age, that activity alone is rare and has been mostly replaced by technology.
3. Write the code:
I'm not big into IDE's (integrated development environment) which is just a fancy way of saying the editor in which we write code. I think for me, it's a visual thing. Syntax highlighting is too distracting. So I use a plain text editor like Mousepad. IDE's also can make people lazy. I think it's a good idea to do your own indentation as an example and to be familiar with best practice in programming, rather to rely on any type of automation.
4. Test the code:
I don't use a debugger. Shock, horror! For me, programming and fixing code is one of the fun parts. Ambiguity has a certain attraction. The challenge of figuring out why something doesn't work, draws you closer to a greater understanding of the how and the why, and I like that.
5. The Test drive:
Do I like the clicky? How does the UI function, do I need to tweak it? Let's get a friend to test drive it. Let's test it on more than one machine, including hardware and in a VM.
6. Ready for mass production?
Test, test and then test again. We're ready for release. But not before we upload the new package to a test repository (a new Linux Lite implementation and the inspiration behind this thread and the recent Lite Patch issue), then perform an update via both the command line and Install Updates.
7. All's well that ends well:
Everything works as we expect it to. Maybe some Social Media announcements, but generally I'll just upload the new package to the main Linux Lite repository for everyone to download via Install Updates.
The work flow:
IDEA > PLAN > WRITE THE CODE > TEST THE CODE > TEST DRIVE THE 'FINISHED' APPLICATION > WRITE THE CHANGELOG > PACKAGE THE APPLICATION > UPLOAD THE PACKAGE TO A TEST REPOSITORY > TEST THE UPDATE FROM THE TEST REPOSITORY > RELEASE TO MAIN LINUX LITE REPOSITORY > REACT QUICKLY TO ANY OVERSIGHT
![[Image: X5qGkCg.png]](http://imgur.com/X5qGkCg.png)
![[Image: 0op1GNe.png]](http://i.imgur.com/0op1GNe.png)
![[Image: LgJ2mtP.png]](http://i.imgur.com/LgJ2mtP.png)
![[Image: vLZcFUE.png]](https://imgur.com/vLZcFUE.png)
![[Image: lrUHro3.jpg]](http://i.imgur.com/lrUHro3.jpg)
