My status this week is:
DONE: Expanded my models with a test first approach
BLOCKERS: Live
GOALS for this week: Get main functionality to work
I am currently working on … a real estate listing site with Django 2.2
I am struggling with understanding … Python @decorators (stayed with generators last week). If you dig deep it gets veeery interesting…
I am finally understanding … generators?!
I have work to show at … Nothing to show for now
My input:
DONE: More Blog tutorial: facelift with bootstrap and spent ages debugging typos! Implemented flask-moment (wrapper for moment.js) which neatly handles times/dates. Currently adding Spanish translation using Babel, which kind of sucks a lot.
BLOCKERS: None really.
GOALS: finish translation and get onto more interesting stuff before the weekend finishes.
I am currently working on … MicroBlog
I am struggling with understanding … nothing currently.
I am finally understanding … python ecosystem, and why its so slow.
I have work to show at … Local only until my tutorial is finished and new version built.
DONE: More frontend (the specs changed)
BLOCKERS: styling range inputs. I am starting to understand those who hate CSS (Hi, @zedshaw 
) I mean , I know it’s doable if you use some hacks and write some 300 lines, but I guess I am not the only one in this world who needs to align datalist tickmarks on a range track.
CSS says you can use labels on datalist options.
What I’d naturally expect from this code:
<input type="range" list="tickmarks">
<datalist id="tickmarks">
<option value="0" label="0%"></option>
<option value="10"></option>
<option value="20"></option>
<option value="30"></option>
<option value="40"></option>
<option value="50" label="50%"></option>
<option value="60"></option>
<option value="70"></option>
<option value="80"></option>
<option value="90"></option>
<option value="100" label="100%"></option>
</datalist>
is achieve this, right?
Wrong. First off, not all browsers display the same thing.
Some only display the tickmarck, other only the labels.
After hacking the display property in CSS, the labels go vertical, one on top of the other, under the range track. (See this pen: https://codepen.io/ioiomano/pen/cc37d3e53b9b388fd4d0bff045d9c4b9)
You need to drink rabbit blood on a full moon, write some more CSS to align tickmarks with their labels.
From MDN:
Note : Currently, no browser fully supports these features. Firefox doesn’t support hash marks and labels at all, for example, while Chrome supports hash marks but doesn’t support labels. Version 66 (66.0.3359.181) of Chrome supports labels but the
<datalist>tag has to be styled with CSS as itsdisplayproperty is set tononeby default, hiding the labels.
It’s 2019 and there’s no easy way to display a range. And I have a deadline
Also, not only the design changed, the backend specs changed as well … I need to integrate more API’s, pull more data, add more models, etc.
GOALS: Finish this MVP
I am currently working on: this MVP
I am struggling with understanding: the specs
I am finally understanding: how HR people are calculating salaries
I have work to show at: none yet
P.S. Pfew, found a Vue component for the slider: vue-slider-component
I hate css and frontends in general. But not as much as I hate UXers!
Seriously though @io_io surely a simple slider would be MVP? Are you over-engineering?
well, there’s only one dashboard page for the MVP and when the client shows it to people that will use the tool, it better looks polished. Not app-ready polished, but presentable.
I’m not sure your client understands minimum viable product. The whole concept is incremental improvement from the basic functionality (mvp), so polishing is literally the last thing that happens.
True, but the client needs to sell the tool, they don’t yet have the funds for the whole thing. They just paid for a cute thing with basic functionality so they can show it to the potential buyers which are businesses.
Be careful they don’t sell stuff you cannot (easily) implement or maintain just to get their funding 
Thanks @gpkesley , I am obviously a noob to all this stuff. Will chat to them tomorrow. They asked how much time will it take for the product to be usable. So the MVP should be ready soon (9th oct).
And after showing the MVP to the potential clients they will most likely want to know when it’s usable. I have no idea yet.
@DidierCH MVP is ‘minimum viable product’. It’s a term used to describe the first shippable iteration of a product during iterative development processes.
It’s often used to demo software to stakeholders and gives a view of quality through working software. It’s a development team’s responsibility (all roles) to help the client describe the goal & purpose to be achieved so they can provide a working solution. By producing the MVP it helps all involve validate they are on the right path or make changes in the solution, long before too much time and effort is embedded. This is really the power of iteration and aims to reduce wasted effort.
It’s based in the view that we learn as we develop and we can react quicker in smaller chunks of development with frequent demos of the MVP for each chunk.
Where things usually go wrong is when a separate team mock up the ‘solution’ and present this to stakeholders. They may spend ages discussing cosmetics that is then passed on to development to delivery. It might not represent MVP for Dev as for example, the simple radio buttons, select list or input fields of a form could be documented pixel-perfect and on-brand, but no one requested confirmation of exception handling messages to accompany them, or even field lengths, or worse still, what exactly the ‘Reference’ field really means…
In these examples, where Dev can not access the client or stakeholders to resolve these ambiguities, they guess or shoehorn something in that they think will be ok. It rarely is as they are Dev not Design, Marketing or UX.
Showing stakeholders the MVP demos the functionality and wireframed design and can help prompt more questions about the developing goal and what is really wanted (because it will frequently change!)
Thank you @gpkesley that is a solid answer. It looks like a very good approach to me when well done. Will think about how I can implement that idea at work. Thanks again.
No problem @DidierCH but much of it is common sense really. If you accept that people can and will change their minds, it makes sense to structure your delivery to be able to react to changes. Too often we hear “you didn’t ask you that in your requirements” so its a change (extra cost usually) so the client gets something they don’t really want.
But on a personal scale, think about when you build something. I doubt we are at the level yet where we can imagine the end solution in our projects and then just implement it. Even with some planning upfront (class diagrams etc) we probably still learn about omissions as we write the code.
If we are writing small chunks of code and testing it as we go (like Zed recommends), being able to ‘demo it’ is a good measure of whether it is a complete unit/module. I find considering this approach when working on a project means I focus on one areas at a time, rather than dabbling in lots of areas and leaving it very messy and incomplete.
Give it a try and pretend you have a client that wants to see your Real Estate project now, before they give you funds for the next part. It might force you to get the MVP done so you have working software in complete functionalities, if not all of them at this time.
Yes it should be common sense 
but often it isn’t 
How would you proceed with my Real Estate project to get an MVP? Would you define all the parts that make up the whole and then finish it part by part? Till you get a minimal viable product?
No the opposite. I don’t know what parts it has but let’s assume it has a ‘view properties’, ‘add a property’, ‘edit a property listing’, etc.
You might work on ‘adding a property’ first so you can get it fully functional (you might well need to mock things here), so it’s demonstrable and you can interact with it. It might have a crude, unstyled front end, lightweight DB and critical methods for routing, taking inputs and saving to DB.
In theory you could demo this and confirm it works but adding a property and then query the DB to confirm it fits the schema. Job done.
But typically, (if you are like me) you’ll want to see the listing on ‘view properties’ part of the software and invest time working on that too in parallel. The trick is to resist that urge until the previous part is completed to a demonstrable level.
I should add that MVP tends to make more sense to teams working on larger applications, where it’s possible to spend lots of time polishing features that no one really wants. If I recall, something like 80% of software features aren’t used regularly so really understanding the goal of the software (it’s MVP essentially) means your focus is in the value adding parts.
Thank you. I think I understand it better now. And I see the part I can get better: make an MVP first and then work on polishing and adding minor features I tend to over engineer things and forget to make something happen… to really focus on an MVP will help to overcome that obstacle.
