As of today it’s been a week since the end of the Python stack. I’ve been too busy enjoying my time off to write any blog posts. This week is probably the only week off that I’ll get for the whole duration of the bootcamp, so I’ve done my best not to waste it. I’m sitting in my wife’s office as I type this because she’s taking a half day for a weekend trip to Michigan and we’re going to leave directly from her work to avoid traffic. Break time’s almost over, however, and I start the Ruby stack on monday! Before that, I figured I should spend a little time reflecting on my experience at Coding Dojo thus far. I also never finished writing about the end of project week, so I’ll start with that.
Project Week Conclusion
The last two days of project week went by in a blur. As presentation time got closer and closer, it became clearer and clearer that we weren’t going to be able to implement all the features we wanted to. Turned out things like emptying the trash, moving files, and sharing were a bit more complicated than we thought. But at least we got our MVP down solid and looking great. Actually, right before the presentation we discovered a bug that wouldn’t allow us to log in! SHIT! We’d been working on the home page for so long that neither I nor Armando had logged out or in for the past couple days, so we had no idea where the bug had come from… (I later fixed the bug during my week off. Turns out it was leftover from before I had implemented password encryption in registration. I had temporarily been storing unencrypted passwords for test users, and thus was not encrypting the password at login. It was an easy fix to turn encryption on, and then everything worked like it was supposed to. I guess we forgot to test login again after implementing the full registration. Oops!)
Luckily, registration was still working just fine so our presentation went off without a hitch. We started by demoing the login, complete with beautiful jQuery +AJAX magic, showed the failed password message (even though the password was actually correct, lol), and then went straight to registration to create a fresh account. After the new account was created, I showed off all the menus and animations, made some folders, and uploaded some files. Armando managed to get the trash and recent tabs working just in time Friday morning, so we were able to demo that functionality as well. Breadcrumbs weren’t an MVP feature, but they made it in there in time for the presentation too. The table-grid view transition was a little glitchy looking, but otherwise working properly. All in all, our presentation went well. We got plenty of questions about how we managed file uploads and storage as well as our plans for sharing. I had been working on sharing that Friday morning and although I didn’t get everything hooked up in time for the presentation, I was still able to answer some questions about how it was going to work.
Presentations went pretty quick since there were only two groups, and after that we went straight into the graduation ceremony. All my senpais that just finished the MEAN stack were ready to head out for their job searches! To celebrate, everyone took off early to go to the bar downstairs, Headquarters (a super cool arcade bar where all the games are free and the drinks are very not free). I went home early to have dinner with my lovely wife!
The Python Stack – Reflection
Looking back, my first stack at Coding Dojo was so fast-paced that it’s hard to remember the exact points in time I learned all the stuff I know now. After finishing up Web Fundamentals, I knew how to make a static site out of HTML and CSS, with a dash of jQuery for some simple animations. Now, after completing the Python stack I feel confident that, given enough time, I could slap together a clone of just about any website and even deploy it! I’m glad that I came in to the Dojo with some limited experience in Python already, because it allowed me to spend less time working on the basics of programming concepts and the Python language and more time working on how to actually use it. My previous experience, combined with the flexibility of Coding Dojo’s learning platform, allowed me to skip ahead to material about things like setting up routes in Flask while some of my cohort mates were still learning what dictionaries were. My advice to anyone considering Coding Dojo or some other bootcamp would be to definitely take some free online courses in programming BEFORE laying down the $10k+ for an immersive program. It will really make a difference in helping get the most value out of your investment.
Speaking of Flask, I have a couple thoughts on it. I can see why Coding Dojo used Flask as our first into to building a full stack. It’s super simple and everything can be done in a single file, with just a couple folders for static files and HTML templates. Defining routes and controller methods in tandem with each other helps you see what’s happening in the HTTP request/response cycle without a bunch of moving parts. Flask taught me how to inject variables into templates and work with the Jinja2 templating language, which is kinda similar to Django’s templating language. Flask also forced me to learn SQL queries and link to a MySQL database, which I still kinda hate doing, but I’m glad I learned how. I think it would be pretty easy to learn Django’s ORM and have no idea what’s really happening in the background, but thanks to Coding Dojo putting Flask first, I have some great foundational knowledge on the subject and can now use an ORM or raw SQL queries depending on my current project’s needs.
Now that I’ve learned Django, I can’t really see myself going back to Flask for anything any time soon, But Flask definitely played an important part in my learning process. Django, on the other hand, seems like more than just an important part of my learning process, but also a valuable tool in my professional toolkit! With Django’s separation of concerns, it really helped me nail the MVC design pattern in a web app medium. Before coming in to Django I was already familiar with MVC apps thanks to my experience in iOS (Thanks for the great naming conventions, Apple!), but for whatever reason someone decided to go with MTV as the Django design pattern instead of MVC. I know they mean the same thing, but come on. Why not just use super explicit naming to follow MVC like Apple does? I’ll have to look into why that decision was made at some point.
For anyone that doesn’t know what MTV or MVC mean, here’s a little explanation. Feel free to skip it if you’re not interested:
The M stands for Model. This is the same for both MTV and MVC. The Model is where most of the data and logic for some app is handled. In all the processes happening behind the scenes, the Model is what is doing all the number crunching.
T is for Template, V is for View. These two both mean essentially the same thing. The View/Template is what the user sees when they use the app. It displays the user interface and the results of all the number crunching that’s been happening in the Model.
V is for View, C is for Controller. This is where it starts to get confusing, and I don’t know why whoever came up with MTV did this. The V in MTV is for View, and the V in MVC is also for View, but the V in MTV is actually the Controller, which is the C in MVC. What? Lol, yeah it’s pretty dumb. Anyways, the View/Controller is what passes information between the Templates/Views and the Model. Remember, the Model does all the number crunching and the Template/View displays the information, but how does the information get from the model? It goes through the View/Controller! Whenever you click some button on the screen of your web browser or smartphone(on the Template/View), information about whatever you just clicked is sent to the server, and is caught by View/Controller. The View/Controller then uses that information to decide what to do. It will probably ask the Model for some new, freshly number-crunched data to send back, and then it sends a response in the form of a new Template/View to display to the user.
And that’s basically MVC/MTV in a nutshell!
So now when I’m working with Django, I just have to remember that my
views.py file is full of Controller methods and my Templates folder is full of Views… LOL! It took a little getting used to, but it all makes sense now. Another thing that I am really glad I learned about in Django is how to write Regular Expressions. In Flask, we were writing routes that accepted variables for either POST or GET requests, but there wasn’t really a good way to ensure that only valid variables got matched to those routes. With Django, all routes are regular expressions! With regular expressions, we are able to more carefully fine-tune our routes to match specific patterns. For example, if we want some variable to be passed only as a number, we can specify that we want our route to only match on numerical digits. With regular expressions, we can choose exactly what route patterns we want our server to listen for, and we know that by the time some variable gets passed to a controller method, it must be formatted correctly. Obviously Regular Expressions are also a big deal for validation purposes, and learning how to use them with Django routes helped with learning how to write patterns to check for valid names, email addresses, and phone numbers. Regexes are definitely another valuable tool in my developer toolbox.
And with that, I think I’m ready to tackle Ruby, head on! I’ll probably still keep coming back to Python for side projects because I really do like working with Django, but I hear that Ruby on Rails really expedites a lot of the busywork in building web apps, so I’m excited to get my hands on it. As for my Doodle Drive project, I still want to keep adding features until it really is a full clone of Google Drive, but for now I think I’ll take a break from it. Coming back to it later will be a nice Python refresher after immersing myself in Ruby.