I had been running Pycharm 2023.1.3 for quite a while without paying any attention to the available updates… I hopped in to add a quick feature to my IT ticketing system and noticed the updates and clicked on it.

This __this__ happened…

I almost shit a brick in horror and wondered if I had inadvertently started VS Code. I tried to go about my mission of adding a simple feature then got disgusted when I had to fight the UI to close a webpage preview of a template.

Google to the Rescue!

I hunted about on Google for a bit then happened across the JetBrains Classic UI plugin. Once installed I had my familiar and powerful IDE back, not some lopped off text editor. I even created an account on the JetBrains marketplace so I could review this plugin and ended up upvoting almost every review I listed there.

I can only hope they maintain the Classic UI plugin. If I wanted VS Code I would just use it for Free — but I prefer an actual TOOL that behaves like a professional integrated development environment.

VSCodification has to STOP

Can we just stop the dumbing down of every user interface? I understand the plight of the nascent end-user that is just getting taking their first steps into computing. But for a seasoned (read that as OLD school and just plain OLD) developer it’s disheartening and disappointing to see good tools turn into kids toys.

The post PyCharm 2024 UI Update appeared first on Dennis Bottaro.

I looked through my logs on the server and found a issues like the following:

Server Log: Harakiri on Worker

2024-05-31 10:08:25 Fri May 31 10:08:24 2024 - *** HARAKIRI ON WORKER 1 (pid: 2, try: 1) ***
2024-05-31 10:08:25 Fri May 31 10:08:24 2024 - HARAKIRI !!! worker 1 status !!!
2024-05-31 10:08:25 Fri May 31 10:08:24 2024 - HARAKIRI [core 0] 10.0.0.20 - GET / since 1717164203
2024-05-31 10:08:25 Fri May 31 10:08:24 2024 - HARAKIRI !!! end of worker 1 status !!!
2024-05-31 10:08:25 DAMN ! worker 1 (pid: 2) died, killed by signal 9 :( trying respawn ...

After checking my other logs I realized it’s not my application. There is something amiss over at PythonAnywere. Quite a few users in the forums are mentioning similar errors. “504-loadbalancer” and “504-backend” seem to be cropping up most often.

There is no notification of system status on the PythonAnywhere Dashboard. This would be a nice feature to add down the road once this current outage is fixed.

Some chatter over on the @PythonAnywere on X shows that a DDOS seems to have started sometime yesterday. This could answer the question “What’s wrong over at PythonAnywhere”

Error Log: OSError: write error

My error log shows this message a couple of times.

2024-05-31 10:13:27,385: OSError: write error

This is not a Django or Python problem. Some critical infrastructure isn’t working properly over at PythonAnywhere.

Update: 5/31/24 11:15am

My ticketing site is working. Will check out the forums to see if anything is posted there.

The post PythonAnywhere: Something went wrong :-( appeared first on Dennis Bottaro.

Deploying a Django 5 Application using PythonAnywhere

I recently developed a simple ticket tracking system in Django for my own use to better manage requests from my team at the office. It consists of two main models User and Ticket with a TicketHistory coming one of these days. The simplicity of my models led me to try using Class-Based Views for the first time and it wasn’t a bad experience coming from a few years of Function Based Views.

Staying focused on simplicity I wanted to see if I could host this basic site without standing up a new Ubuntu server instance along with the required NGINX and Gunicorn stack. I opted to give PythonAnywhere a try and I am quite pleased with the ease of deployment and performance even on the free tier.

PythonAnywhere’s Killer Feature – File Persistence

Before getting too far into this, I need to mention this app runs on a SQLite database. This was a non-starter for some app hosting providers like Heroku since there was no real file persistence. This is NOT the case with PythonAnywhere – there is a REAL live file system that is always available to your application.

Simply stated – you CAN use a file-based data source in your project.

This Elated Developer

Getting Started with PythonAnywhere

I signed up for a free user account, and got straight on about getting my application up and running.

Out of the box, PythonAnywhere supports instant setup for Django 3.X and 4.x projects. Being I was on the bleeding edge with Django 5.0.4 (Thanks Pycharm!) I had to go about setting up my environment manually.

Touching the Naughty Bits

I needed to create a my own virtual environment to run Django 5. This was as easy as could be after running a few commands in their “Console” section I was pip installing my requirements. Something PA does that I was not used to is launching virtual environments using a “workon <environment>” command. I’m guessing this might be an Anaconda method of managing virtual environments, but it was a change for me from source/bin/activate that I have become used to.

Once getting the environment setup I needed to get my code up to the site. Since I had yet to push my project to GitHub I needed to zip up my project directory and copy it up using their “Files” section. Then unzip the file in the “Console” section. After that I was a few settings changes away from rolling my app live.

After making need changes to my settings.py file and the website configuration file, I was up and running after a couple of failed starts due to my own path naming errors.

Running Live and Loving It

My simple ticketing system has been up and running for about a week at the time of writing this post and it’s utterly fantastic. Performance is great, their support seems top notch, and they are very clear that there are real developers available to help you when you need it.

Check out PythonAnywhere and see how it fits your needs.

The post The PythonAnywhere Experience appeared first on Dennis Bottaro.

The error came down to my missing something from views.py in the form instantiation from the POST data.

def handle_files(request):
  if request.method == 'POST':
    form = MyForm(request.POST, request.FILES)
    if form.is_valid():
      form.save()    

I was missing the additional parameter for the FILES from the request object. I ran across so many articles that didn’t show THAT, or I was just missing it, that I spent far too long on trying to solve this simple error.

Update: This is covered in the Django documentation, but somehow I managed to over look it every single time I read it.

Dennis Bottaro, Harried Programmer in a Hurry

Hopefully this saves someone the time it took me to resolve this issue.

The post Django File Uploads Fail appeared first on Dennis Bottaro.

class MyModel(models.Model):
    job = models.CharField()
    address = models.CharField()
    start_date = models.DateTimeField()

    def custom_group_header(self):
        return self.job + "; " + self.address

This worked and got the needed data on the report, but seemed far too cumbersome to be the correct way.

The Better Way

A few days went by and I was asked to add more related data to the report group header. I almost created yet another custom method but just knew there had to be a better way. I googled around and came across a Django feature suggestion involving expanding a CHOICE field form the choice key to the choice value that was ultimately rejected. But the rejection comment held the answer I was looking for.

By virtue of the grouper having the list objects you can ask that list for the first object and access it’s model fields.

How to Refer to Additional Model Fields from the Grouper

group.list.0.field_to_display

So, for my next header change I did the following in the template without having to add unneeded code to the models.py file.

{% for job in jobs %}
	<tr>
		<td colspan="4"><strong>{{ job.grouper }}</strong></td>
		<td colspan="2" align="right"><strong>Start Date: {{ job.list.0.start_date|date:"Y-m-d" }}</strong></td>
	</tr>
	{% for task in job.list %}
	<tr>
		...
	</tr>
	{% endfor %}
{% endfor %}

The post Django: Grouper – Show Additional Fields appeared first on Dennis Bottaro.

It took me quite a bit to time to stumble across this, as the Django documentation does not mention it.

If you have a ‘related_name’ set for a ForeignKey field on a model, USE that related_name as the MODELCHILD_SET name when trying to access related objects.

Working Example

Based on the example Polls app in the Writing your first Django app Documentation.

<h1>{{ question.question_text }}</h1>
<ul>
{% for choice in question.choice_set.all %}
    <li>{{ choice.choice_text }}</li>
{% endfor %}
</ul>

If you have in your models, the Choice model in your models.py file.

from django.db import models


class Question(models.Model):
    question_text = models.CharField(max_length=200)
    pub_date = models.DateTimeField('date published')


class Choice(models.Model):
    question = models.ForeignKey(Question, related_name='choices', on_delete=models.CASCADE)
    choice_text = models.CharField(max_length=200)
    votes = models.IntegerField(default=0)

You will need to use that related_name in place of the modelname_set in the template to access the child objects.

Thus, your template would need to look like this otherwise you won’t get any objects from the ForeignKey relation.

<h1>{{ question.question_text }}</h1>
<ul>
{% for choice in question.choices.all %}
    <li>{{ choice.choice_text }}</li>
{% endfor %}
</ul>

I sure hope this helps someone scratching their head and endlessly checking their model names.

The post Django Models Parent Child Template Rendering appeared first on Dennis Bottaro.

I have to say that this excellent python training course covers PLENTY of topics that new programmers and old-timers from other languages (like me) will use almost daily programming in Python.  Everything from IDE selection and setup through Exception handling and Web Services are explained and put to use.

I highly recommend this course to anyone looking to expand their knowledge of Python.

The post Training: TalkPython.FM appeared first on Dennis Bottaro.