shortstackdevs

[shortstackdevs]

Actual image in actual Amazon web docs explaining their product advertising API.

[shortstackdevs]

.forEach ALWAYS returns undefined

[shortstackdevs]

aces ++

I’m here to tell you that you don’t actually want to learn to program. What you want to do is solve a problem. Maybe there’s an app on your phone that you don’t like, and you want to come up with a better solution. Maybe you’ve decided that you want to have a website. Or maybe you want to build a game.

[shortstackdevs]

What’s the difference between assigning a function to a variable and naming a function?

Ie. the difference between:

 function end (done) {    done();  }

and

 var end = function (done) {    done();  }

From JLRishe on StackOverflow:

“The difference is hoisting. When you use a function declaration statement (i.e. what's being used in the [first example]), its definition is "hoisted" to the top of the scope (read: function) that contains it, and therefore even if you try to reference it before the code that defines it, it will be available.”

So the first function is hoisted and the second is unhoisted. In the second one the variable `end` needs to be defined before it is referenced otherwise the code will break. Whereas, in the first example, the function may appear later on in the code.

[shortstackdevs]

It brings me joy

that these are instructions I can follow.

django.contrib.humanize A set of Django template filters useful for adding a “human touch” to data. To activate these filters, add 'django.contrib.humanize' to your INSTALLED_APPS setting. Once you’ve done that, use {% loadhumanize %} in a template, and you’ll have access to the following filters.

Except how do I call the function in the template?

[shortstackdevs]

Malbolge

Malbolge (the 8th circle of Hell) was designed to be the most difficult and esoteric programming language. (x)

"Hello World" in Malbolge:

('&%:9]!~}|z2Vxwv-,POqponl$Hjig%eB@@>}=<M:9wv6WsU2T|nm-,jcL(I&%$#"`CB]V?Tx<uVtT`Rpo3NlF.Jh++FdbCBA@?]!~|4XzyTT43Qsqq(Lnmkj"Fhg${z@>

[shortstackdevs]

Regex Sounds so Cool

Hey what's the difference between a full-blown programming language and regular expressions? Something to do with Turing completeness says Paul. 

Regardless, these cute exercises should help you out with regexs: http://regexone.com/lesson/1?

It was like a lightbulb went off when I realized there are them things used to make unique URLs in Python.

(Also if you know the answer to that first question we'd love to hear.)

[shortstackdevs]

Poetry in Python

Run a Python shell in terminal. 

Type import this.

it will return you a poem about the Python manifesto:

Beautiful is better than ugly. Explicit is better than implicit. Simple is better than complex. Complex is better than complicated. Flat is better than nested. Sparse is better than dense. Readability counts. Special cases aren't special enough to break the rules. Although practicality beats purity. Errors should never pass silently. Unless explicitly silenced. In the face of ambiguity, refuse the temptation to guess. There should be one-- and preferably only one --obvious way to do it. Although that way may not be obvious at first unless you're Dutch. Now is better than never. Although never is often better than *right* now. If the implementation is hard to explain, it's a bad idea. If the implementation is easy to explain, it may be a good idea. Namespaces are one honking great idea -- let's do more of those!

[shortstackdevs]

Difference between methods and functions

1.  Methods are functions

2. Methods are attached to classes, and are used on instances - in other words, a person, not Person, the class.

3. Methods always get the instance passed in as the first argument - self

That's basically it.

-Paul Handly

[shortstackdevs]

When you import something into Python

where on earth is it being imported from?

[shortstackdevs]

FORMATTING NOTES ================

courtesy of Alex Chung*

--The closing parenthesis in a function, dictionary, list, etc that spans multiple lines should match the indentation of the top line:

SETTINGS = (      # Stuff )

     NOT:

SETTINGS = (      # Stuff      )

--Add notes to yourself to describe a section or the purpose of a function, setting, class, etc.      --Titles should be directly above the sections they describe

#Like so KILLER_CODE = []

     NOT:

#Like so

KILLER_CODE = []

     --Add "close tag" notes in the html 

<!-- NOTE --> <div> <p>Cool code, bro.</p> </div> <!-- /NOTE -->

N.B. Writing notes in all caps is a stylistic choice

--Clump thematic settings together

e.g. all SOCIAL_AUTH settings in your settings.py can go together, likewise for info about timezones

--This is an old school style for leaving notes from one dev to another

# TBD = To Be Determined # ??? = I don't know how this works # XXX = Broken

--General rules of thumb: You want less "boxes" in your html. Try not to make divs in divs in divs. --Ways to organize your CSS:

.login .login-form .login-form-button

--OR-- .login .login .form .login .form .button

--Booleans normally take a structure like is_thing so they read more like statements

is_visible = True

*Alex doesn't have Twitter. How can I properly credit such a man?

[shortstackdevs]

GET vs POST

GET and POST are typically used for different purposes.

Any request that could be used to change the state of the system - for example, a request that makes changes in the database - should use POST. GET should be used only for requests that do not affect the state of the system.

GET would also be unsuitable for a password form, because the password would appear in the URL, and thus, also in browser history and server logs, all in plain text.

from django docs

[shortstackdevs]

excuse me

[shortstackdevs]

AJAX, JSON, and CORS! Oh my!

Due to some polite nudging from Maya I'm back in the blogging saddle and I bring this up not to draw attention to my lapse in updates, but rather that I had been holding out for an epiphany or two before writing here. It was pointed out to me that the struggle and the learning before the comprehension is not only worthwhile, but really the point of this blog to begin with. What better way to document learning to code than quite literally as my brain is putting it all together? Without further ado:

Today I worked on Instagram API all day. Literally all day. No question it should not have taken so long, but it did. Let's look at why. (Disclaimer: Sometimes I explain things as I understand them, and not as they necessarily are. I apologize for all terminology and lessons I bungle in the retelling.)

The dev of the hour today was Dan, who at 5 sat down with me for 45 minutes and showed me what I had been trying to piece together all day.

What I was trying to do was this: Pull in the most recent photo from Instagram tagged #betapic.

Simple. Straightforward. And on top of that it was an assignment I had done over the summer during my front end course. So this should have been done and done, yeah? Squared away and good to go.

The thing is, the code I had written over the summer looked like this:

$.ajax ({

    code code code

})

And the legacy code we had in the web app I was working on? Well that looked like this:

$.getJSON(

    code code code

)

And when I attempted to reconcile the two? Well, the error message I was getting in the console looked like this:

No 'Access-Control-Allow-Origin' header is present on the requested resource.

So, what was going on? First I googled the error message and was immediately led astray. The act of googling the problem is all fine and dandy, but my interpretation of some of the Stack Overflow responses led me down a rabbit hole about CORS, that is, Cross-Origin Resource Sharing. Duh!!! CORS is for when you need to send things from one domain to another. (This is where my earlier disclaimer applies.) If you are sending information across sites, CORS is there to make sure it is sent securely and with the right permissions stored in the header of your site. A website can say "all-access" and a site can say "no access" and I imagine it can say a number of things in between, the use of header permissions really depends on the size of your site and the privacy of the information you have.

You can take a gander at header permissions in Chrome by opening up your DevTools (Inspect Element) on a website, preferably one that pulls in information from another website. Click on "network" in the top bar. Make sure your little flashlight icon is blue (i.e. selected) and click on XHR from that menu. From there you'll notice a subset of tabs one of which is called "Headers." Under Response Headers you may see something like

Access-Control-Allow-Origin: *

if a website gives header permissions to all other websites.

With this I could see I didn't have the Header permissions needed to access the Instagram goods. So I mistakenly began to lay the blame on Django, my scapegoat. I googled and re-googled "No Access-Control-Allow_Origin Django" imaging that Django was putting up invisible Berlin-data-walls, blocking me from Instagram and the freedom of speech. When savior Dan did arrive he kindly told me, No, this has nothing to do with Django allowing or not allowing cross-site permissions. Turns out no one has header permissions to access Instagram data, it isn't secure enough for a site of Instagram's size to just have that info floating around.

I needed a new angle. Maybe the API request link (is that even remotely the right word?) was pulling down outdated data? Nope. The little link I got from the Instagram API site was working a-ok and pulling the latest photo.

So I went back and looked at the code I had from over the summer, the working code. I stared at those two lines. AJAX vs. JSON. I googled the difference between the two. I did not understand what I googled, Dan had to explain to me what was going on. What I remember is that Ajax... whatever is happening in ajax is also happening in json, but json does some additional things which I do not know what they are. You're welcome for that explanation.

My code eventually looked something like this:

$.ajax({ url: "https://api.instagram.com/v1/tags/betapic/media/recent?client_id={{ instagram_client_id }}", dataType: "jsonp", success: function( response ) {     # Gettin those pics

} })

It was important that I define my json from Instagram as jsonp which is another way to send info between browsers, like CORS, but not in header permissions. 

And now it's working.

But why do ajax and json take different parenthesis?

[shortstackdevs]

who made this?? who made a django pony??

[shortstackdevs]

Some Django tips

My website is live! It doesn't have 100% of the functionality that I want yet, but I'm amazed I was able to build the structure for the thing I wanted to exist (a dynamic list of all connections between Stephen King books). 

Here's some annoying Django gotchas that I've learned along the way... you're welcome.

Datetime

You can *either* do from datetime import datetime and then put datetime.now in your code, or you can do import datetime and use datetime.datetime.now. ¯\_(ツ)_/¯

Fixing migration errors

Django does this cute little thing where when something is wrong the first time you try to migrate your database, it will keep giving you the same error no matter what you change. A handy trick that I learned to fix this is that you are allowed (even, I think, encouraged?) to delete your migration files to make it forget that you did anything wrong. Somewhere in your Django project (I think it should be the same directory where models.py and views.py live), there will be a Migrations folder. Don't delete the folder, but you can delete all the migration files inside it. Fix your error, try migrating again, and you should be good.

Default values

This one is super annoying because it only happens after you have some information in your database. If you add a new row to a table, Django freaks out because it doesn't know what value to put in for the existing stuff in your database. I don't know what the real rule is, but what I've found generally seems to work is the following default values for the following field types:

text fields: null=True

foreign keys: default=0

datetime fields: default=datetime.now (see above)

In some cases, you can resolve this by making the fields optional (blank=True), but it doesn't always work: eg, I had problems with that datetime field because I wanted it to be an automatic time stamp, which can't be optional.

[shortstackdevs]

Traceback Errors, Non-Nullable Fields, and Lots of Random Guessing

OMG I hate traceback errors. There's nothing like that feeling when you're sailing along, adding random things to your code to see what happens (but totally sure it's gonna work because why wouldn't it?), and then you make your migration and get 100 lines of error messages. I just spent 45 minutes trying to fix one. But I fixed it! Here's what happened.

I tried adding a new model, with a basic charField, and I even preemptively gave it the ol' (null=True, blank=True) treatment. I ran python manage.py makemigrations and got this stupid thing:

You are trying to add a non-nullable field 'category' to item without a default; we can't do that (the database needs something to populate existing rows). Please select a fix: 1) Provide a one-off default now (will be set on all existing rows) 2) Quit, and let me add a default in models.py

Ok... right. So I selected option 2 and tried fiddling around with it and migrating it a few more times but kept getting the same error. Ultimately, I figured, why not try option 1? Never tried that before. Seems reasonable.

Please select a fix: 1) Provide a one-off default now (will be set on all existing rows) 2) Quit, and let me add a default in models.py Select an option: 1 Please enter the default value now, as valid Python The datetime and django.utils.timezone modules are available, so you can do e.g. timezone.now() >>> blank Invalid input: name 'blank' is not defined >>> timezone.now()

(I didn't want to use a time stamp for the default, but I didn't understand what else I could use. Thanks for the helpful feedback, computer.) Anyway, I figured it didn't really matter what I put in because I wasn't going to use that default permanently anyway. We're just talking one-off defaults, right?

...and then I got a million lines of traceback errors. None of them made any sense (they're referring to files I've never heard of, like __init__.py and schema.py, and some scary-sounding thing in manage.py that says execute_from_command_line(sys.argv). I tried messing around with those files but they all looked like the sort of thing I shouldn't touch.

So, nevermind, I just decided to comment out this new 'Category' model because I already made it nullable but for some reason that's not working, and it's causing nothing but trouble for me. I'll just figure it out later, yeah? Onward with the rest of my changes! 

Nope... this stupid traceback error still wouldn't let me do anything. I couldn't migrate ANYTHING. I'm not gonna lie, I teared up. But then I googled one of the errors (int() argument must be a string or a number, not 'datetime.date' - clearly caused by throwing in that timestamp) and some helpful commenter suggested deleting the offending migration files. Which I totally forgot you could do.

Deleted. Fixed. Still haven't figured out the nullable issue, but at least now I can move forward with other stuff until I can get someone else to tell me why it's not working. Progress!