The following modules are being removed from NearBeach;
Quotes and Invoices
We currently feel that they do not fit within the new NearBeach’s project management system, as they are more LEAD generating. We will toil with the idea of bringing them back into NearBeach in some capacity.
Development Alpha 0.27.3 released
The newest version can be found on PyPI. Please note it is not backwards compatible with the 0.26 branch.
It has been 3 months since we started doing the refactoring/rewrite of NearBeach. A lot of work has gone into completing just 1 object. When the release candidate (RC 1) comes out this week, it will only focus on “Requirements” object.
Why are we releasing this as an unfinished product?
Good question – we actually want to;
Show the work completed so far,
Get feedback on this work before we apply the changes to the other sections of the code.
Why are the other objects and components disabled?
We really didn’t want the site to have both “New/Old” themes on it. We are focusing on only one section of the code.
What objects will be applied next?
The following is a simplified road map
Release Candidate 1 – Requirements
Release Candidate 2 – Requirement Items
Release Candidate 3 – Organisations/Customers
Release Candidate 4 – Projects
Release Candidate 5 – Tasks
We are hoping to have the majority of this completed well before the year’s end. We are hoping all the hard work that we have applied at the requirements object, will be transferable to the other sections.
Will this release be buggy? Should I use it?
This release will be buggy – we are only releasing it to get feedback on the UI/UX. We are also going to test it thoroughly as many of the functions within it will be utilised in the other objects, i.e. projects, tasks. We will NOT recommend using it for any production environment.
If you end up using it for testing purposes and find any issues, please submit a ticket at https://bugzilla.nearbeach.org
It should be noted that this has been more of a code re-write. Only small sections of the code have come through untouched. Recent fixed to the models.py has lead me to rewrite all the migration files again, which means we will not be able to allow upgrades from 0.26.2 to later versions. We will work with anyone to help update in this situation.
We will be doing another release soon, however a lot of the functionality of NearBeach has been stripped out. The next releases afterwards will be focusing on putting that functionality back in.
NearBeach will be getting some help from another developer, which is exciting news for us. They will be helping with constructing the new objects and help document everything.
I am hoping to have more information by the end of the weekend.
In the last year and a half I finally took a web development job full time. In that time I have learned a lot of new technologies like Webpack, VueJS, D3 etc. I am now turning around and seeing that I can improve NearBeach tenfold by applying what I have learned.
The majority of the issues left with NearBeach revolve around the UI/UX, and code base that I can improve. For example I can structure NearBeach a lot better – so the code flows a lot nicer and it becomes easier to program for.
Here are good examples of this are;
view.py file currently sits at being 10711 lines long. Finding sections within that code takes time.
Some forms are overly complex, i.e. the quote line items, and are becoming harder to fix any bugs or issues associated with them. Without the server time taking too long to render the form.
Code is being repeated over multiple spots – for example the following code project_results = project.objects.filter(…
No structure for the JS/CSS files
The general fixes for these would be;
Split the view file into separate files for each modules. This will make each file smaller and easier to find the class you need
Move a lot of the complexity out of the back-end and place it into front-end. VueJS is a powerful library that can easily deal with complicated forms
Move these repeated codes into their own python file, with their own functions
As I am not releasing any new functionality – I am planning on implementing these changes during beta.
One major issue NearBeach faced when we started getting users to test, was the simple fact that users HATED the UI/UX. I can not blame them, as I am not good at expressing visually. Design has been my weakest skill by far in web development. It has been something I have not given up on though – and in the last year I have learned a lot.
I have decided that NearBeach will require a massive refactoring, both the UI/UX and the backend code. This will hopefully lead to a cleaner code base, and a streamline UI/UX.
I have a lot of plans for NearBeach. Many modules in my head that I want to implement into NearBeach. So why am I wrapping up to release a stable version? Simple – I had to draw a line in the sand somewhere. This is the best place to start – I can’t be stuck in a development cycle forever without a release.
What is coming up – how many version for the 0.26 branch? There are currently 2 planned 0.26 releases looking at fixing bugs and issues. After the next release I will be doing a system wide test of NearBeach – from there I will determine if we need any more releases.
What will happen after release? NearBeach 1.0 will be a long term support (LTS) version. How long we will support it will need to be discussed and planned. This is our very first LTS stable version of NearBeach. NearBeach will also have a secondary branch that will be for new development – once again, we are still in planning how this will work and we will have more information soon.
NearBeach started out as a learning project for myself. I had programming knowledge gained from my years of knowing C/C++, SQL, and other languages. A friend mentioned moving one of my prior ticketing systems from C++ to a web based application. NearBeach became that application.
As I learned more and more about web programming, NearBeach gained more and more modules, and essentially evolved into what it is today.
There is nothing wrong with this approach, however it does have a few shortcomings. One of those shortcomings is that I have learned a lot more effective ways to program for web development.
The next major release of NearBeach (lets call it 2.0 for now), will focus on the following;
Refactoring code, making it easier to read, quicker to implement new functionality, more efficient, have a defined structure.
Design update – NearBeach looks very bootstrap, and the reason is it is. I am not the best designer out there, however I have hit the books and youtube to try and improve my front end skills.
More modules – I will always be either adding or refining existing modules within NearBeach. If you require any extra features, why don’t you hit us up on our forums – https://help.nearbeach.org
Before we start any of these tasks, we want to create a stable code base. One with as few bugs in it as possible.
Bug fixes, more bug fixes and some more bug fixes. It is currently very important for us to fix all current issues with NearBeach.
The new version of NearBeach can be installed using PIP
BUG563 – Instructions need to have “Group Leader” in them
BUG593 – Read only user in chrome has weird layout for “Run Sheet”
BUG621 – Table overflow needs scroll in administration group
BUG624 – Password Reset needs new layout
BUG626 – User settings – alert not in alert mode
BUG634 – Can not apply bugs to project
BUG637 – Organisation search is not character case insensative
BUG647 – New project under assign task
BUG648 – Adding a whiteboard to customer gives permission denied when accessing
BUG649 – Group projects dashboard shows closed projects
BUG651 – Read only user – can create kanban board
BUG655 – Linked objects in requirements showing requirement items
Short term future goals
We will do another bug finding and fixing run to try and get NearBeach as stable as possible before releasing into the wild as a stable product. We are currently looking for feedback, and are planning what to do in the future about developing new functionality.