Month: August 2017

Preparing for Clowns, or what I learned from a Twitter-fight

The CodeNewbie chat last night was about dealing with bullies, and, since that dovetailed so well with what I’m working on right now, I thought I’d try to be a bit more active in blogging about what I’m doing.

You see, I think my app is 90% finished, but I’m taking a break from features to get ready for the public. Which, really, means, to get ready for the jerks. You see, the worksheet generation app isn’t a social app. The user’s interaction with it is basically all centered on the user and their own groups and classroom resources for their groups.

But, contributions are shared. That is to say, if you need a translation for the word ‘web app’ for one of your groups and there isn’t one in the system, the system just asks you for one. But then, the next guy profits by the translation you added. And you’re profiting from the resources added by others.

The Twitter Fight

But then, I got in a bit of a fight on Twitter. I’ll post sometime on the idea of ‘defending the ancestors,’ and why I don’t like the term ‘the ancestors’ being used as a dog-whistle for racism (racist dogs!) but that was what it was about. And it wasn’t nice.

While I’m a middle-child and can handle Internet strangers being mean to me, I realized that the guy I was fighting with had the advantage: his Twitter handle was only for his trolling. My Twitter handle connected to all my life, and he could see that, use it in a fight. And, because I tend to fear the worst, he could start being a jerk in other parts of my life.

I realized that, when I start posting about the worksheet generation app by name, with links, anybody who felt like they didn’t like me (and there have been a lot of those people in my life) could create a free account, and just throw a wrench in the works by adding terrible resources.

Imagine if a legitimate user — maybe even one paying for the service — wanted that aforementioned translation of ‘web app’ and got something like ‘where we see the naked photos of your mom.’ Even worse, what if that person — like I often do — didn’t proofread that worksheet before handing it out to students. (At some point, worksheets will be emailed with a mouse-click.) What a nightmare.

Worse than paranoia

I talked myself back down from “Twitter people will be mean.” After all, the solution could easily be ‘just charge everyone.’ Who’d pay me money for the privilege of trolling me?

Then I realized I shouldn’t worry about Twitter trolls making accounts and being jerks. I should worry about people just like me thinking that they’re being funny. Or, even worse, thinking that the resource they’re making is appropriate for their students. After all, we teach adults, whose to say that we can’t include “your mom” jokes?

My real  nightmare is someone either testing out the system, playing around, and putting random crap in… Just to see if it really appears in a worksheet.

Of course there’s a solution

I can deal with it. Of course I can. There’s not a problem without a solution.

My interim solution is, for now, giving users the opportunity to explicitly say “this is part of an inside joke with this group.” You can easily add resources that will only be used for a single group. Easy.

The other thing is pretty simple: all resources are immediately available to the person who creates it. Everything else has to be approved, first. As users are added, it will be possible to say “the resources added by user_x will be automatically available,” but, until then, it means that I’ve invested a lot of time already (all morning today was spent creating the interface and the backend that will enable this level of moderation) into the project of investing a lot of extra time in this project.

And that kinda stinks. It makes me like people, as a group, just a little bit less.

Advertisements

The Discipline of Perception

After reading the Obstacle is the Way, by Ryan Holiday, I recently resolved to re-read it more slowly, writing about what I read in order to reflect. This is part of that, and may only be of interest to me.


 

The first story in the Obstacle is the Way is of John D. Rockefeller, and the education he gave himself — basically — by remaining level-headed in times of panic. The lesson seems to be that there cna be a financial panic happening around you, but if you choose to see it as an education, that’s what it is.

My favorite line from the chapter is actually from Warren Buffet, who is credited with summing up Rockefeller’s mentality this way: “be fearful when others are greedy and be greedy when others are fearful.”

The actual lesson of the chapter seems best summed up here:

Outward appearances are deceptive. What’s within them, beneath them is what matters.

We can learn to perceive things differently, to cut through the illusions that others believe or fear. We can stop seeing the “problems” in front of us as problems. We can focus on what things really are.

This comes at a good time. In fact, I’m several weeks late in writing this. I’ve been working as hard as I can on the dynamic-efl worksheet app and consistently feel as though I’m almost there.

I’m so very almost there that I’m getting lazy. There is a (growing) list of minor things that I want to fix, once I get it so far that I can start asking others to take it for a test drive. But, it’s getting harder and harder to reach that point, because I didn’t do something I should have: I hard-coded everything to use the new domain name.

That means that it’s almost impossible to run in development mode on my notebook, and everything has to be tested out on the website. No big deal, really, except that everything is slowed down by committing every minor change to GIT, pushing it to Git Hub, and then pulling it to the Linode server and restarting the uwsgi service. Gah, it’s frustrating. (And that frustration is part of why the list of things I’m going to fix ‘later’ is growing.)

The reason I thought to read this now was that it was just this afternoon that I realized “I could be using this as an opportunity to practice overcoming problems, rather than feeling sorry for myself.” And that’s what this could be. Should be.

There are all kinds of lessons that I should focus on learning:

  • using django’s url tags to avoid hard-coding anything at all
  • setting up a project so that it can be easily changed over to ‘production settings’ with only a few changes in the settings
  • serving static files with django (turns out just copying a template from startbootstrap.com is not enough to make a landing page)

And that is what I’m going to try to do. There isn’t really a rush, as long as I can use it to make my own worksheets.

The trick is not seeing what it looks like, it’s seeing what it is.

Hats of to Django Europe

Something I feel like I should add, as I seem to be live-blogging my situation right now, is that, when I was at my most frustrated last night I signed up for an account with djangoeurope.com, rationalizing that they promised a 30 money-back guarantee.

Today, I asked for the money back and without a whimper it was returned before the end of the day. Good on them.

Can’t say I’m not learning

I continue to be frustrated by whatever it is that is interfering with my rented Ubuntu server serving up my worksheet-generating django site. I’ve even come so far that I’ve written up my troubles in a Stackoverflow question.

While I’m decompressing, I thought I’d summarize some of what I’ve been learning. A lot of what I did felt like trying things wildly (Is this the right path? Maybe up a level?) and restarting services. Then, I took an answer to this question on Stackoverflow to heart:

You should try to invest a bit of time in understanding all the components involved. For example you have merged the .ini uWSGI file with nginx.conf that is completely wrong. I can suggest you to start from here: http://uwsgi-docs.readthedocs.org/en/latest/WSGIquickstart.html

Try to understand every step (expecially the part about using official sources instead of distro packages). Start deploying without nginx (only uWSGI), and only after you are sure the thing is clear, you can proxy it behind nginx.

I went through the steps in the quickstart tutorial one at a time, writing a short Python program to do ‘hello world,’ and moving forward from there. It was helpful, and I have learned.

For example, I guess I never really thought about it before, but I think that uwsgi is the part of the whole thing that actually runs my code. I’ve certainly seen something like this often enough:

web browser <=> web server <=> wsgi <=> django code

And, to be honest, I never really thought about what ran my code. When you run the development server, it feels clear.

It looks like, whatever I’m doing wrong, I have the uwsgi service incorrectly configured, such that it can’t load my code. That’s obviously a problem. I just don’t know how to fix it (and I’m not even sure that I know it, this is all a question of me reading error logs, googling, reading answers to questions that are only similar to mine, and trying to extrapolate).

Still, in addition to beginning to wrap my head around wsgi, here are some things I’ve learned:

  • A few new console commands in linux, including ‘env,’ ‘useradd,’ and ‘nano’
  • Where some error files are stored ( /var/log/nginx/error.log — I can type that from memory)
  • How to use ‘sudo’ and ‘su’
  • Starting, stopping, and restarting services

There are some things I’d like to know more about, but my brain feels too melted to really absorb new information. They include:

  • How to uwsgi and nginx communicate via sockets? What does that mean? What is a socket file?
  • I only did the bare minimum of ‘hardening’ my server. How vulnerable is it? What are the chances that it will be attacked deliberately, or by someone just attacking every website in the hopes that one is vulnerable?
  • I’ve realized that all of the http://localhost:8000/…/ in my Django templates will need to be updated to use the domain name I bought. How do grown-up developers deal with this? How will I test things here ‘in development’ before sending it to ‘production.’ (I feel like a poser using those words).

So, yeah, I’m frustrated, but not so much that I’ve opened the red wine. (See my last post.) If I had a bottle open, however, I’d raise a glass to learning.

Fear and Frustration

I was going to only title this post “Fear,” and write about how hard it has been to finish up my worksheet generator project, because I knew I was close to having something finished that I could show to my friends and colleagues and get them to beta test it.

I had a timeline — I’d have the website up by the end of the week, show it to a close friend and fellow teacher next week — and be using it by the weekend, while soliciting other beta users. By Christmas, I wanted to be running Google ads.

Fear

The basic premise of this post was planned in a few parts:

  • Pointing out that I often talked about just wanting to have something finished
  • Talking about how it feels to tell people, as an unqualified EFL teacher, that you’re working on a coding project
  • A brief summary of the challenges of converting a project that had been working in Tkinter into a Django application
  • And, last but not least, the surprising feeling of having to force myself to do the things that needed to be done to get the project ‘ready for deployment.’

It was strange to not want to work on the project. But I’d set myself a deadline and my classes will be starting back up. I want to use the website version.

With a bit of time and reflection, I realized that I was afraid of the next steps. Soon, I’d be exposing myself to the possibility of learning that other people don’t think my app is amazing. How strange.

Knowing that, it was easier to push through it. Which brings us to part two of today’s post.

Frustration

I don’t know why I think of Django development as ‘simple,’ what with the heartache and frustration I’ve experienced. Partly, I suppose, it’s because each of the problems I’ve had has been solvable though Stackoverflow and patience. And, probably, because they mostly amounted to me making a silly mistake.

And then I tried to deploy my app.

It was working fine, using the development server on my notebook and, even though it would be a long time before I ran out of tweaks to add, it was time.

So, I did the following:

  1. Paid for an account at Github
  2. Bought the domain I wanted on hover.com
  3. Paid for an account at Linode
  4. Spent hours in telnet and with various tutorials
  5. Paid for an account at djangoeurope.com
  6. Went back to experimenting with Linode, because there are more tutorials specifically for them
  7. Opened some red wine
  8. Seriously considered no longer coding
  9. Googled ‘django deployment’ just once more
  10. Realized I probably ought to be blogging rather than doing this

The power of words

Now that I’m on my second glass of wine and have been thinking about it for a while, I realize that I’m confronted with two problems:

  1. I don’t know anything about servers, of what I have to do to get them working
  2. I don’t know what I don’t know about servers, in order to google it.

That’s the thing about coding, half the battle is just knowing what the coding community calls the thing you’re trying to do. Once you know that, you can use some patience and elbow grease to get it going.

But now? Now I’m stuck. And I’m frustrated.