Time shared development Part II - or Project H?

A little bit more than 6 months ago I changed my daily work to "time-shared-development".

Spoiler: This was a good idea...

But as I mentioned, I do not use any software or website to track my projects. Ok - JIRA as a bug-tracker for my two main projects...

There are so many "new" words and websites to handle your agile programming, your development team, and your projects. By doing some googling, you really get overwhelmed by the different approaches. Some are looking not so bad, but most of the systems are much too big for some little project tracking. Most of them have no detailed information on the workflow and of course, all systems/websites want your money as a monthly fee. 

I really, really dislike the tendency to do everything in a browser on a website. No, I hate this! That's why I always use an App if it is available. 

The question is, do I need this? I think the "time-shared-development" is still a very good idea, so let's compare the pros and cons.

Pros

• Work did not get boring
• Every day a new task in a different environment
• If I get stocked on a problem, I could work on a different project and wait for a new idea
• Other projects are not sleeping and are still improving
• No induction period in projects that have been dormant for a long time

Cons

• All projects take more time to be completed
• The progress (next step/problem) of every project has to be kept in mind.
• Shared code that has to be used or could be used in more than one project can easily be overseen 
• Problems can be too simple be pushed aside (see Pros)
• Progress-points of projects could easily get mixed in mind

So two cons depending on keep the progress and/or the actual problem of every project in mind. For two projects it is doable... But how many projects could you keep track of, without any todo-list? At this point, I'm still not 100% happy with this kind of workflow. Should I start project H and start coding software for this task? How long would it take to develop a usable software? Which are the necessary main features to start with? Is a simple text file on the desktop enough? Or an Excel sheet?

OK, perhaps first take a look at the problem. Of course, I use me FDK for every project and as my MVVM-Plugin is nearly ready, I will use this also for my projects. Some projects must be refactored to this new version of my framework. For new features I always decide if this is a feature - only for this project - or should I write this as a generic Class/Unit for my FDK. Many projects have a partial feature that is similarly usable in other projects after minor changes.

For example, many mobile apps storing data into a local database, if no internet connection is available and after a reconnect the database has to be synchronized over a REST Service. This is - of course - included in my FDK (Client and Server). Most of my projects are using this implementation as a start and doing some improvements on top of it. That is fine for Project A, but it would be nice if Project B could also get the benefit of improvements in Project A? But how to code special and also universal for more than one project? Maybe this is possible, but not if you have to keep everything in mind. And here comes project H into play.

I need a perfect representation of all project states and progresses to get an overview at which point I need to developer feature A because Project A, D, F are at a point where no progress could be made without this feature. Because all three projects a evolved as far as possible to the point where this feature has to be implemented, it must be easy to find similarities and every project could use the same improved implementation and only have to do some minor project specifications.   

hmm... if this is not the case I spend hours and hours in developing project H (my version of agile software developing tool, if you did not read part I) without any benefit.

At the moment I have not made a decision. Perhaps you have also some ideas - I would love to read your comments. But don't try to convince me for a web service... ;-)

I've made some POC's how to drag and drop "Features" from a backlog into a sprint, show sprints and points, but I've not tried to draw any Gantt, waterfall or whatever the name is of my final graph...

Of course, if I start project H, it will be FMX to be able to do everything on the road over a mobile device. Did anybody else need this kind of "simple" software? Should I do my first open-source project or try to sell this software? Perhaps it depends on how many developers what's to help me with this project. So again please leave a comment or give me a call...

btw. Happy x-mas

New Style-Designer Software

Hello!

Perhaps you read my post on FB already - if not - I'm planing together with MVP Steffen Nyeland, to develop a new "Bitmap"-Style-Designer for FMX and perhaps also for VCL or to make it work closer together, to create a style that is working on FMX and VCL. (If this is possible - never tried to create a VCL style so far) 

Perhaps you followed my posts about my tests with the current designer.

• VCL and FMX Styles and the Style designer.
• Did you try to design an FMX-Style?
• FMX-Styles Update

One problem with designing a new designer is - of course - the result has to work with the RTL. It would be possible to create a new StyleBook component, but the main styling should work with the given RTL. The main focus is to get the software with much better usability.  

If you are interested to work with us please give Steffen or me a call. Perhaps you have a good idea of how the designer should work, but do not have the time to help with the development, we would like to read your ideas. If you are working with the BitmapStyleDesigner and just want some improvements - we would also like to read that, too

Should we design our new designer mostly like the "original" or should we go in a completely different way? 

Without wanting to influence your ideas, this is our ideas so far:

• new UI
• FMX-UI for "all" platforms
• custom style colors
• live preview 
• hook for own preview window
• better documentation! (Where setting A is used in component B)
• external icon management (load icons and compose "the" bitmap)
• no more draw a rectangle around every image.
• use SVG to create different resolutions

There is more, but many parts are still under consideration - we also have not decided if we do this as open-source or not...

Android 64 Bit device list.

Finally, we have the compiler to do the Android-64 deployment. But do we have 64-Bit devices?

The problem is, even if the CPU is 64-Bit maybe the installed OS is only 32-Bit. Of course, this is only a problem if you care about it. 

If you are using the non-native stuff - the CPU doesn't care and also if it is 32 or 64 bit.

But I like to debug my stuff, so I need a 64-Bit device and I really dislike spending a lot of money on the kind of device, because my daily drive is an iPhone.

Spending more the 300€ for a device just for some debugging is crazy.

If you google for a 64-Bit Android you do not find anything, because nobody cares about this.

It is also very hard to get the information on what CPU and what version of the OS are running. You have to install AIDA64 or some other test-apps.

So if you have the proof that your device is 64-Bit and also has a 64-bit OS installed and costs less then 250€ please leave a comment.

Lost in Units...

If you start a new project or perhaps the POC of your new project, you normally save the main form and the project file to a sub-directory of your choice.

And then?

How do you name your units or your forms? Do you put your units in sub-directories? Do you have naming conventions?

In the past, I used a "w" in front of my unit name if it was a form. (Winform)  And of course, the Filename had only 8 chars because pre-Windows 95 filenames had this limit...

I hate projects where every unit has it's own sub-directory...

So how can we do it the right way?

With MVVM or I think any other pattern to separate the Forms from the Business-Code you get more units as without or the "Thing" we call RAD.

Comparing RAD with MVVM we get 2 more units (ViewModel, Model) perhaps beyond the Model we get 2 different implementations of a DTO Class. Perhaps one more Unit for a separated Interface-Unit. So in the worst case, we get 6 units per "View/Form". If it is a From that contains more than one view it gets "worse".

I like to have "View/Form" related units together not all Forms in one sub-dir and the modal or the ViewModel at a different place.

If you have a project with 200 forms, with MVVM we get something between 600 and 1200 units. This is a mess if you have no strategy for your unit names or where to put the files.

So where is your limit putting every file in the same directory? For me it's the height of the project tree in the Project-Window. A little bit of scrolling in the tree is fine but if this tree is too big I get lost. So some time in a growing project I have to put files into sub-directories. I hate to do this, because if I need a reference to these units, every unit has to be included in the DPR file or I have to include every sub-directory into my search path.

Let's start with naming.

Since I'm using MVVM I use the "MVVM-Naming" in every project, so

MainForm -> Main.View.pas
Global interfaces -> MyInterfaces.pas

Global settings -> config.pas

Global ifdef -> IFDEF.pas

Application startup -> bootstrap.pas

Application construction -> Composition.Root.pas

Forms are named "XXXX.View.Pas"

ViewModels of course "XXXX.ViewModel.pas"
Models of course "XXXX.Model.pas"

"Just Units" - that are not service-related are placed in a sub-Directory ("no platform") only if they are not related to a special platform.

Platform related Units I have sub-directories like ("Windows","iOS","Android","OSX","Linux");

So my "normal" Dir-Tree is looking like this:

- Artwork of course for all Icons and Bitmaps especially for FMX!
- BIN as Target to resources
- POC for Proof on concepts
- XE10.* for RTL Source file copies (I always have to change some files/parts)
- Tests for all Unittests.
- tools for all these small tools you need to build this project.

For a smaller list of matching units with the namespaces I had - or we had - an idea at our last Delphi-breakfast today.

So please support my feature request :

RSP-27158

Thanx!

MVP of the Year / German candidates.

Hi!

The election of the Embarcadero MVP of the year has started.

If you like my stuff please vote for me!

Here is the link to Olaf Monien's homepage (Developer Experts) if you like to vote:

Please click here!

This is only for German MVP's every region has it's own system.