Article 001 - Hello World
written on: 2015 - 01 - 01 (happy new year)
The default html page that comes with the webspace here at
SDF, with all due respect, is not very standard code. It started with a <title> tag followed by the <html> tag. Of course the <title> tag should be within the <head> tags to begin with, and certainly not first. However, it still works. You might also come to find that you don't really even need to use <html> or even <body>, you can just start typing in whatever markup you like, and as long as it is formatted correctly, it should work in most browsers. HTML markup is not very strict (or most browsers interpretation is not strict) and it is amazing how many mistakes you can have in the code and still see it work correctly in many browsers. In many cases it won't be until viewing in a particular browser with stricter rules that you finally see the result of your bad code. I'm not really happy about this though, I kind of like strict guidlines in coding because it enforces protocol and thus creates a more orderly code base on the web at large, also decreasing the burden on browsers to parse and display web pages correctly.
I made this new account at SDF and settled on the name "sql" because I have been in web development as a freelancer and/or self-employed business for many years, and it's amazing how many of those years were spent in headache over sql problems, namely MySQL. As a result it came to my realization how much of a web dev I have become, unintentionally, over the years, and also how much I do actually care about coding and protocol. This bit of enlightenment shocked me because I otherwise commonly consider myself to be an
extremely off the wall, out of the box, perhaps even
renegade developer. I hate frameworks and strict guidelines, I like my development experience to feel more like art, to be able to be creative and organize things how I like them myself without having to follow someone else's protocol. I also love the fact that someone else can organize their code however they want as long as it works together with my code and as long as we can read and understand each others methods.
I believe that everything should be coded from scratch, and I struggle to hold back the spewing fires of hell whenever my eyes accidentally gaze upon an article preaching any type of dogmatic structure within the coding world. Such articles are stupid and spread a virus of poor foundational beliefs within the community of beginning code enthusiests, and yet, somehow, they seem to eat it up.
"I've worked in this industry for XYZ years and I've been a member of major household name softwares for XYZ Mega Corp Inc. and I have such and such to say about how you should make your software."
I can't stand this type of stuff.
Let's face the facts, frameworks and API's make things easier for people, particularly beginners to coding, and in many cases a
good framework can speed up productivity in application development, but is there really a
one shoe fits all sizes framework out there for anything? And is it really so hard to make your own framework "per scenario"?
What terrifies me the most about this type of cult following, firstly is just that... it is a cult - and nothing more. In other words, the blind leading the blind into a valley of jagged thorns and wild beasts. Who is to say just because you have done successfully for a certain span of time at a certain company that you should be writing the book on how to do "anything". You certainly may if you please, but don't make yourself a self-proclaimed expert and inspire large groups of young and naive coders to follow in your steps. You could be wrong.
But furthermore, what really worries me about this type of framework followship mentality is the lack of creativity and education which come from these types of programming habits. It causes people to lose the vital lessons in the core operational behavior of languages, the interaction between the code and the machine, and incidentally creates coders who are dependant on a framework which may or may not be best suited for all scenarios. You do not need to reinvent the wheel, no, but in order to make a car you should certainly understand wheel physics, and you should be able to improve upon those physics for the betterment of both your business and global improvement at large.
This is becoming sort of a rant, which I genuinely did not intend, but I think it is worthwhile to keep these things in mind when embarking in your programming education. Frameworks almost
always prove to make overly-complicated, inefficient, and bulky applications. I don't want to start any debates and I am not trying to push an agenda, I am simply saying that it should be universally "understand-able" that the educational and foundational implementations of application development are much better achieved with "understanding", not blindly following a trend that is
supposed to be a quick and easy trick to get you up and running in the business world. Is that how you want your cook to make your food? Should they skip the core understanding of nutrition and health and just get to the part that makes it taste good? If so, fair enough, but please do not invite me to lunch.
This topic of frameworks is a bit of a side track, I was originally writing on the topic of web dev and how SQL became so important to me, but I just had to get that off my chest, and perhaps it relates strongly to this topic because it brings up two important points. One being, how did I study in order to get myself into the position that I have today and two, what are "good practices" when getting into application development. This is not at all to trash-talk frameworks, I use them myself sometimes, but I know when is the right time to use them and when not, and it should come as no surprise that in many cases the best option has always been to
not use a framework. And I can easily explain why in just one sentence: Once you start using a framework you are often bound by its limitations, and if you are not the author of that framework yourself you will actually find yourself slowing down production as opposed to speeding it up while you try to find work-around after work-around to meet your application requirements. In addition to this, you are adding tons and tons of useless code to an application, perhaps even adding useless processing. Such is the reason for sayings like "You don't need an aircraft carrier to destroy an ant hill."
End rant.
Let's focus on what are good practices and on why SQL became both a burden and a savior to my development education. Firstly the main reason I like to avoid frameworks (or API's) is because it lessons my education and growth as a developer with each application I make. It is much better to know the core functionality of the code and the machine in order to make efficient and stable apps. A good example of this would be using any language to make a game with a lot of physics or graphics. If you don't understand the core language well and depend upon a framework to keep you developing, you will quickly run into many problems that can slow down the game's intended functionality. Granted, not everyone knows how to make a 3D graphics and physics engine, and I would not dare to get involved with that myself, but if I depend 100% on someone else's engine, and it doesn't behave exactly how I want it to, then what can I do? Perhaps that particular engine was designed more for graphics efficiency where I need power in behind-the-scenes physics processing. So do I drop the engine and look for another? If I know the core workings of the language itself I don't have to make this hasty decision. I can dig into the framework or API and modify the code as needed. But there is another problem with this. Now I have to study the framework, dig through the code, alter it, test it, potentially spend time in correspondence with the maintainers or even wait a few days for responses in some forum or social group. So which is ultimately faster? (1) Going through that process with every app you make, or (2) simply knowing how to make stuff from scratch, do it, and reuse your own existing code to grow bigger and faster with each app you make. I'll take the later of the two options. It's a longer, harder road, but much more gratifying.
That being said. Do whatever works best for you. There are many cases where a good API or framework work out just great. It's usually for much simpler applications, lightweight business apps and such. Just do whatever works best, keep your code clean and organized, keep your apps efficient, and always keep "reusability" in mind when making your code.
Now how does this apply to SQL?
My first website went up in about the year 2000. It was a one page, hand-coded HTML website with a painting image of Conan the Barbarian I copied from somewhere else and some text saying that I was an upcoming fantasy artist or something like this. Of course this would be somewhat dangerous today because of copyrights on images, but at the time the web was wild, and after all, I was just trying to figure out how HTML worked. I didn't intend to keep that image any longer than it took me to get my own art into the computer via scanner or camera, but that was a chore itself back then too. Oddly enough, even then, the time when "Napster" was casually allowing people to share copyrighted MP3 files, I was advised by family and friends to remove the image as it looked as though I was trying to take credit for someone else's work. That's just an oddball memory now, but I thought it historically interesting and funny nonetheless.
The site was brendonschumacker.com as is fitting for an artist named Brendon Schumacker. Basically, I was studying HTML at that time here at SDF and when I discovered how cheap it was to buy a domain and some hosting space I didn't hesitate to register a domain and get some space. I was advised to go with "pair" hosting, which to my surprise is still available. They offered a cheap UNIX shared hosting space with basic FTP access. You could literally log in via FTP and see other people's website files there, and there was nothing more but a disclaimer to the end of "You should not look at other people's files under penalty of being banned." I hope they have spruced up their security since then. Regardless, I learned a lot at the time, and it was great fun learning how to design things with HTML and a bit of image assistance on my very own website.
As the years went by I continued like this, adding more to the site, scanning my artwork, writing articles, learning more and more about HTML, Javascript, CSS and then later Flash. I vividly recall being somewhat irritated when I learned something new that I didn't even know existed previously. For example, I felt I was doing just fine with raw HTML and some image assistance when some people started talking about CSS. I didn't want to have to learn another language, and I actually thought that CSS was some type of troublesome attempt to complicate something already well enough. And in fact, many major sites of the time didn't even use much CSS. You would be surprised by how many professional websites relied upon tables and images solely to design their pages. As time went by it became apparent that I was never going to make a site as good as some of my online friends were making if I didn't resort to CSS, and so I reluctantly caved in, but later found it to be much more powerful of a tool and became greatly appreciative of it. However, to this day, I still find it to be long-winded, overcomplicated, and lacking-in-semantic-sense of a language. I often dream of designing a lightweight replacement language for CSS. I'm sure many would argue the need for this.
At any rate, I learned CSS bit by bit as time went by and it was at about this time, probably 2002, that a tipping point came in my web design studies. I was studying programming at the time and started getting a lot of chat about using programming languages for my sites such as Perl or PHP. Again, I was frustrated and didn't want to learn "yet another language" in the midst of everything I was learning already, but there came a day when I wanted to make a twenty-some page comic book display and I realized that making this page by page was going to be a real chore. I was dabbling in Perl a bit at the time and found it to be a bit frustrating, but I also was an avid student of C++ and Java and I managed to publish my comic pages at first by making little apps that automatically generated the HTML pages for me. It must have been about that time when a friend at SDF, recognizing my situation, recommended I try PHP which is a very simple language for publishing automated web pages. But still, no SQL, just PHP with a lot of hard-coded data, and some text files as a database.
SQL was the last frontier. I had taught myself HTML, Javascript, CSS, Flash, Imaging Softwares, Perl/PHP and such, all just to make this simple comic book viewer, not to mention all of the work put into the art, and now people were suggesting that I use SQL to make things "easier"?!? I was livid! Yet another language, yet another protocol, just for this!?! A comic book viewer??? But I couldn't deny the facts. If I were to continue to make websites that kept up with the competition, or even if I just wanted to keep up with it as a hobby, I would never be able to keep the site up to date with this long and winding process of generating pages through so much hard coded data, and using text files (flatfiles) as databases was becoming more and more frustrating due to the lack of utilities available for sorting and organizing my data.
I wondered if it would ever end. Would there ever be a day when I didn't have to study yet another language or protocol just to keep up with my hobby, and whether or not I would be able to go on as such. Luckily, to this day, I have really not needed to learn much more after SQL. This is what today is known as the "full stack" of web development. It includes the basic client end such as HTML/CSS and Javascript and server side development generally including a scripting language like PHP or ASP and with connection to a database such as MySQL. After having this full stack, you don't really need much more unless you are getting into Flash games or other such multimedia entertainment.
So that is what "sql" means to me. And the funny thing is, after all of that, what I think I really would have done if I had known better, would be to learn SQL first. It's the data that matters most, and knowing how you are going to organize your data makes everything else fall into place, even the design depends upon this - despite the fact that in business design is often what's produced first, unfortunately, as we live in this "what you see is what you get" business world.
In conclusion, if there was any point to this article at all, I would say that having a proper idea of what you are making first and taking the time to design an application properly is key to success. But I also greatly encourage reckless passion in your work and avoiding too much blind cult-like following of any popular frameworks or API's. It is always better to learn from scratch and appreciate the lessons that come as a result of the hard work put into it. And then, most importantly, "have fun". This article was written directly into a single HTML document using Vim text editor with some raw HTML code, and I had a blast writing it. If you made it this far, thanks for reading, and I hope you enjoyed and have a great day!
