It’s funny how my imagination was completely anihilated when I actually read django model field source code.

I thought a Django Model was dedicated to designing the database.

But a Model field is not a DB Field.

A Model field has a DB field, and a formfield method.

Unfortunnately, formfield is not changeable unless you override the method which means creating your own model field.

Also unfortunate, Model has no form() method like their fields have formfield() method.

https://github.com/jpic/django-adapters/blob/master/docs/source/tutorial.rst

django-adapters new proposal ! This time less clumsy and I hope probably more like what Marc had in mind !

It’s been probably 30 hours I’ve spent trying to contribute to the django-adapters. This article describes the approach we take when making investment audits on software @ YourLabs, and my conclusions on this project.

I started by reading what had been done and issues. My first mistake was to not be patient enough to really read and profoundly understand absolutely every piece that had been done.

It seems to me that what django-adapters tries to do is invent a new pattern to solve the kind of problems we usually deal with as developers:

https://tech.people-doc.com/welcome-to-the-virtual-open-space.html

This tells a story of a 24/7 ongoing hackaton with remote workers from the world.

A small anecdote about one of my most recent failures ! Now it’s up to me to be a better coder next time ;)

When I rewrote django-dynamic-fields into facond, I still had Form/Rule/Action/Conditions from ddf.

When the code got to the point where i was satisfied with it i wrote the tutorial.

This is how I figured this lib had just no need for the “Rule” component.

Hopefuly, both python and js had serious unit test coverage, so I just removed the Rule stuff from Python and JS, changed all function signatures, and kept on fixing stuff until tests passed again. This strikes me: if i had started by writing the tutorial, I would not have wasted my time TDDing a component that I actually didn’t need.

Yesterday, I confessed my guilt of writing shitty DOM manipulating JS code live in the browser, and said no, never again.

Due to positive feedback in the django-users mailing list, I’m writing how I actually plan to change how I do JS in Django apps. Believe me, it’s preventively fixing issues i’ve had with JS in Django apps during the last ten years. Nuff said, let’s hack !

Let’s create an index.test.js file:

https://medium.com/@__amol__/going-isomorphic-with-python-and-react-f4664183f0c4

Great one <3

Victory on JavaScript, let’s build another Django on top of Django :) With LOVE

When you start applying best development practices such as TDD, you discover that you make much better software.

First, you can TDD your python code with anything, django has a test runner, otherwise you have pytest and many friends.

Then, you make python to interact with javascript. In the Django community, it seems that there is a conscensus around “use selenium to test your JS”. I’ve been like this myself for years, but the thing with selenium is that it’s functional testing, not unit testing, it does bring short term ROI, but on the long term it becomes costy to maintain over time.

Found another way cool app shared by Linus Lewandowski on django-dev mailing list, here’s the excerpt from django-12factor:

“The Twelve-Factor App” is an awesome methodology for building SaaS apps.

django-12factor makes Django more 12factor-y. Right now, this focuses on the Config - “Store config in the environment”; Heroku users with addons will be particularly familiar with this.

Still not sure of the benefits? Check out “Twelve-Factor Config: Misunderstandings and Advice”.