[Tutor] Looking for some direction

[Jugurtha Hadjar]

Hi,

It seems you have a good overall idea on how you would tackle the project.


First, have you talked to the people you are trying to build the application
for, or are you the very people you're building this for?

If you're building this for other people, try an figure out common scenarios
on how they're doing things. As developers, jumping to code is tempting but
I think it comes at an unnecessarily high price we pay later.

Second, a document that explains what your application does in the 
present tense
to show these people might come in handy based on your users telling you 
what
they do daily. Written before code.

"AutoAwesome allows you to track the vehicles in your fleet. You can 
easily [insert
what the end users have described] in a list of features."

That document will elicit reactions and feedback. Again, it's easy to have
fantasies about how broken their workflow is and think we know better and we
can just code away and build the perfect product that will inspire awe when
finally revealed. I get the sense that you might be lucky enough to know 
exactly
what the needs are, but in case it's not for you, talking to users is 
important.



On 5/11/19 7:59 PM, Cranky Frankie wrote:
> For the Model or persistence layer I want to use SQLite. For the View or
> GUI I want to use wxPython. For the Controller I want to of course use
> Python. I'm also planning on using Git for source control.

If you're using SQL, SQLAlchemy for the ORM (Object Relational Mapper) 
might be
worth checking out. One benefit is allowing you to avoid writing raw, 
possibly
unsafe queries. However, if you are comfortable writing SQL, then by all 
means
just start and ship a first working version 0. A first working version 
in the
hands of users will get you feedback on what really matters which 
neither you
nor us can think of right now.

One thing to do a bit later would be to decouple the persistence layer 
from your
application. i.e: not make assumptions on which persistence technology 
you're using
in your application.

For example, in one project, we could save to a database or to Elastic 
interchangeably
without the "application" changing because all the parts that are 
"specific" to the persistence
technology used were contained in the appropriate, specific, module.

Again, this all doesn't really matter right now. What matters is building an
application in which you can go through one simple scenario from start 
to finish by
the end the week..

> 1) For the IDE I'm most comfortable with Netbeans/Java, but I'm forcing
> myself to try and get comfortable with PyCharm. Is it worth sticking it out
> with PyCharm, or should I go with the Python module in Netbeans? Or is
> there another IDE I should look at?

I'd recommend to work with the IDE you're most comfortable with to 
produce the application.
If you want to try another IDE, you can play with PyCharm when you're 
not working on
your application.

The goal here is to have a working product. Your users don't care which 
IDE you've
developed the application with. Yes, tools are important up to the point 
where focusing on
them prevents you from shipping the product you were trying to optimize 
the tools to ship
in the first place.


> 2) For wxPython I'm finding a lot of the documentation is outdated. Is this
> book any good:
>
> http://www.blog.pythonlibrary.org/2019/05/08/creating-gui-applications-with-wxpython-now-available/
>
> Or is there a better book/course/website I should be working with? Or is
> there a better grahpics framework at this point for a traditional desktop
> app?
>

One thing to think about is having the core of your application 
decoupled from the
technology you use for persistence, view, or other things.


For example, if you have to create a user, format addresses, parse text, 
etc. You
can have functions that do each part that are blind to whether you're 
using wxPython
or PyQt and only understand text.

You can then use these functions by importing them whether you're 
building a web
application, a Terminal User Interface, or a desktop application since they
don't make assumptions.

In other words, having utility functions you can import from different 
parts of
the projects, or from other projects, that you import is better than 
having say parsing
done by a method in a wxPython widget.

You can then concentrate on the functionality and not bother with the 
"viewing"
technology by building a console application first. Show it to the users 
where they
could simply input text and you could display the results on a terminal, 
*then*, worry
about the specificity.

Again, the goal is to have software that *does* something, then make it 
look good, unless
the end state itself is looking good.


> 3) For the O-O part, I'm comfortable with Inheritance and Composition. Do I
> need to worry about any of the more advanced design patterns? This app will
> be for vehicle ownership - tracking maintenance, etc. Nothing fancy.

Not worrying, but keeping the goal in mind: a first version of the 
application by
the end of the week.

The "Nothing fancy" reminds me of Linus Torvalds' email:


"""
I'm doing a (free) operating system (just a hobby, won't be big and
professional like gnu) for 386(486) AT clones.
"""


> 4) I plan to write my Use Case in Libre Office Write.
>

I think using plain text (like Markdown) would be better, instead of 
binary format. This
way you can use version control to track changes on the documents and 
see diffs.

I'd also recommend using GitHub or GitLab (they have free private 
repos). You can use that
to have your code somewhere else than your laptop just in case and treat 
it like a real
project with issues, deadlines, milestones, branches, etc.

You can have issue templates (create your own) for features and bugs. 
You can also have
pages/static site for your project generated automatically that can 
serve as a pitch or
documentation that's written as the project matures, instead of as an 
afterthought.
Check out `mkdocs`, or `gitbook`. I switched from gitbook to mkdocs.

It's also useful to document assumptions and rationale. Often times, you 
write something
and no one remembers why it was implemented. Did the user ask for it or 
did we just guess?

Documenting rationale is very useful because you'll know why you 
implemented a feature, and
why you got rid of something.


> For the UML diagrams,
> is there a simple app to handle that? I don't need it to generate code but
> I'd like to have a nice class diagram if possible.

Have a look at `pyreverse`. You can write the code and then point 
pyreverse on the
directory, and it will generate the diagram for you to a nice document 
(pdf, png, svg, etc...).


> 5) I'm really having trouble envisioning the GUI screens. How does one get
> a handle on that? Just draw the screens on paper, or what?

Simplest use case working by the end of the week.


> Any ideas very much appreciated.
>

Recap:

- Set up a project on GitLab or GitHub or something to save progress
- Talk to users and eke out use cases if you haven't already done so
- Write a simple document that describes what the product does (don't 
use *will*)
- Show it around and see if you got it right. There ought to be a 
priority use case
- Create issues on GitHub or GitLab for the functionality explaining why 
you're writing it
- Keep functions dumb (your phone number parsing shouldn't care about 
wxPython or Qt)
- Console first. Validate usefulness. First spreadsheet wasn't Excel.
- Work on the branch/fork, etc...
- Show your work. Tweak. Merge.
- Next issue.


There's a problem to be solved. Every day we forget that is one day too 
many of suffering
for the user.