Using Javascript Semicolons
Semicolons are ugly. One of the nice things about Python is that you don't have to worry about them. The trade off for significant white space may be strange but it works for me. I wish Javascript was more like Python in that regard.
One interesting feature of Javascript is semicolon insertion. The idea being that if you miss a semicolon at the end of a statement, that's okay. Javascript will automatically insert one anyways.
In the past, I skipped semicolons in my own projects. Then, one day I did some research. There is some debate out there on the subject. But ultimately, trust the smart folks that are widely respected in the Javascript world. Here is Doug Crockford's take on the issue.
"Each line should contain at most one statement. Put a ; semicolon at the end of every simple statement. Note that an assignment statement that is assigning a function literal or object literal is still an assignment statement and must end with a semicolon.
JavaScript allows any expression to be used as a statement. This can mask some errors, particularly in the presence of semicolon insertion. The only expressions that should be used as statements are assignments, invocations, and delete."
It's tempting to ignore Crockford. The way my code is formatted leaves me feeling that my source is invulnerable to masked errors that can happen when semicolons are left out. But do I really want to find out I'm wrong the hard way? Not really. It would be foolhardy to pretend Javascript will treat my lack of semicolons the one way Python does. So semicolons it is.
Nginx and uWSGI
Due to desire for control, my best choice was to make architecture choices for my own personal web stack. That meant picking out a web server and/or application server. AngularJS and Flask were the two known factors here. So what to choose? Gunicorn? uWSGI? Apache? Nginx? Something else? Even after much googling around, it was hard to say what the best choice was.
So I asked. From that Reddit conversation, my takeaway was that Nginx and uWSGI were going to be the best bet.
Now, to be sure, it was tempting to throw out other questions. Why not Gunicorn? Isn't Apache more widely used? Doesn't uWSGI complicate things with too many configuration choices?
But I didn't ask. It wasn't necessary. For one, googling for those answers is a lot easier if I really wanted to know more. For another, those sorts of questions could potentially start a flame war. Why stir the pot on people who are only trying to help you?
Flask-SQLAlchemy
This was a real struggle for me. For the longest time, Flashmark used plain SQLAlchemy. I knew of Flask-SQLAlchemy but failed to see the point of it. The non-Flask version allowed a database layer that was indifferent to whether or not it was operating in a web application. It could be supporting a command line app for all it cared. Why ruin that with an extension that makes the model level scream "I depend on Flask!"
Then I came upon this in the SQLAlchemy documentation.
"Some web frameworks include infrastructure to assist in the task of aligning the lifespan of a Session with that of a web request. This includes products such as Flask-SQLAlchemy, for usage in conjunction with the Flask web framework, and Zope-SQLAlchemy, typically used with the Pyramid framework. SQLAlchemy recommends that these products be used as available."
Even after reading this, it isn't 100% clear to me what flask-sqlalchemy does for me when it comes to reconciling sessions and web requests. Aren't sessions an ORM thing? Do SQLAlchemy Core users like myself need to care about sessions? Is there some sort of connection between database sessions and web sessions? It's all weird to me.
So it came down to this. Who is the smarter and more experienced person when it comes to using Flask with SQLAlchemy? Is it me? Maybe the writer of these docs knows her stuff when it comes to this. In the end, she was the one I trusted more on the issue.
To be sure, it wasn't easy to make the switch over to the Flask-SQLAlchemy extension. There was a lot of legacy code to switch over. It was not fun. But it did work out in the end. Everything is stable. No regrets there.
Humble Pie Is Yucky
It stinks to admit that one doesn't know enough to do one's job "right". Quite frankly, it's easier to not start at all. But such is the nature of software development. It's all about taking those two leaps of faith. It's a leap of faith in others. It's also a leap of faith in yourself. Be bold but also humble.
