Jackson’s Blog

The way humans get computers to do what they want is through “programming” and we program in a “programming language”. In a way, it’s how humans communicate with a computer. When I program, it’s more like talking to a computer than anything else. Talking is what keeps me clothed, fed, and sheltered.

In English, you say whatever you want in any way you want. You can even redefine what words mean. In a programming language you have a similar freedom.

A framework, on the other-hand is a self-imposed method of doing things. In order to do anything within the framework, you must follow these constraints; otherwise, it can’t be done.

Why would anyone voluntarily limit their own freedoms? The answer is collaboration and consistency.

The downside of a framework is the need to remember what these constraints are. The upside of a framework is that through such constraints, you know exactly where a file should be located, how things should be called, where things should be placed and etc. A person who jumps onto the project who is familiar with the same constraints would also instantly know where everything is place, how to place everything, and etc.

When using frameworks, developers should be careful that we don’t over customize the framework. Over customization will cause new developers who know the framework to be unable to find all the things they would need to.

I love frameworks for mid-scale to large scale applications, but I find them unnecessary for simple scripts.

When you’re writing a massive application, if given a choice to use a file manager to manage files or to allow the application to manage the files on its own, it’s much preferable that allow the application to handle the file placement logic. This way, the application’s database can be put in charge of maintaining the file locations ensuring that there are no conflicts and that there is a centralized location to find everything. When an application is maintaining the files, there isn’t even a need for a descriptive name to a file, since all relevance will be maintained by the database. Since you’re only interacting with the files through the application, the application can ensure that the file exists, the file won’t be overwritten, and upon deletion, there are no dependencies on this file.

In the case of major applications, where it’s possible for many components to have access to the same files, I recommend that all these interactions be performed through a centralized file management core. This way, if we were to change the file management logic, it can be easily performed at a single location.

Data inside a database should always be post-processed and ready-to-use-as-is. If you can rely on the data provided by the database to be usable as is, then you’ll save yourself a lot of string processing work. Think about it this way, if you have a string, let say “orange” and it’s stored in the database, and you had another string called “apple”, along with other fruit based strings stored in the database. When you do a search for these fruits, you can specify a where condition and then the fruit the name. Even with for usage, you can use the fruit name as is. Whereas if these strings had all these weird characters in it, “orange\’s” and “@pples”, then the where statement will no longer be as effective. Not only that, during run-time, you’ll have to have code to handle these weird characters appropriately. So if you’re ever inserting data into the database save yourself some problems in the future by ensuring that the strings are properly processed.