Around 24 hours left until deadline of the assessment… I was just lucky to notice the deadline for this reflection journal to be in a few hours. Almost made the mistake of assuming something and expecting it to be some time after, or at the same time as the main assessment. Whew!
Unfortunately, I’m almost certain I haven’t fully understood a part of the assessment. More specifically the second bit with writing sql queries in a text document. I can do it in Python, I can do it in the document, just not… Cross-document. Maybe I’m not supposed to? I don’t know, it’s unclear to me. But how I understand the task is that I’m supposed to write queries in tinygearz_queries.sql that queries the tables in tinygearz_setup.sql ? I haven’t been able to figure out how to apply inheritances to sql, to read or import that document into another .sql document. I’m suspecting that’s rather done in console, and the .sql just provides the queries or something, but at this point I need to prioritize and finish up the main python implementation instead. Perhaps I’ll have spare time in the end to figure it out.
I wonder if it’s normal among professionals to love programming, but more so the opposite for databases. Perhaps it’s just the creative in me. Programming is in some ways like building with lego, or composing an orchestral soundtrack. Databases feel like secretary work. I don’t know, other than I do know databases won’t be my big personal drive and motivation in the future. Which is fine, I believe. Putting on management’s boots, it’s better to have a team that is self-aware of their weaknesses and a finger in the ground to know where to allocate assets. So in a team environment, I’m fairly sure that’s exactly what I’d go for.
But…! I do find it useful. Boring, but definitely necessary. I’ve had a long lasting hobby of tinkering with websites, and setting up various community resources, forums, etc. So I’ve indirectly introduced myself to MySQL through that. Now I feel like I have a better general sense and understanding of databases, enough so that if I find time after studies to get into that again, this newfound knowledge may come to use.
Pythons eat on average four to five times a year, just as much as I’ve interacted with Python. Which is not good, to be quite frank. Good for me, anyway. I feel rusty now as I try to pick up Python again, in preparations to work on the assessment. The saving grace is to look back at my project files for the previous programming course as a refresher. I don’t consider myself particularly skilled with Python, but I do feel I have a decent mind for programming. Decent enough to know my first Python project was absolute crap! Hehe.
Well, not exactly crap. Unorganized, perhaps. It’s functional, solid, does what it set out to do, but in no way innovative or clean. Which is why I dedicated most of this morning to figuring out inheritances and operating cross-files in Python. Mostly because that’s what I’m used to from my projects in Larian Studios’ toolkit, and the capability to say, write functions in one file, and the menu configuration in its own file, then perhaps user interactions in a third.
So far, following lectures haven’t really… Paid off? To clarify that, I’m a very visual-practical oriented guy, I need to see and try things done in practice in order to understand it. Someone, or some text just verbally telling me how something works or how to do something, rarely if ever works at all. So nearly all year, watching lectures have been more about not missing out on important info, rather than learning the content itself. There’s the occasional “A-ha!” of course, and it’s by no means a waste, it’s just not an efficient learning method for me. I am enjoying this course though, and it’s comfortable to listen to the lecturer, which is important to me. There’s been a few cases where I’ve struggled understanding what someone says, because of their accents. So it’s partially been about understanding what they’re saying, rather than what they’re talking about. Thus, I’m happy with this course so far. Even when I find learning new things of this nature very hard and reliably empties my pack of Ibux.
In the coming days, I’ll have to look into learning how to use SQLite with Python.
I've had to step away for a few days, and already feel really behind. Not really sure what can be a good solution for times like this either. What I mean by that is, I have some obligations that can't be ignored, just like school, and sometimes they overlap. So my week isn't really Monday-Friday structured, rather improvising week-to-week which days are most suitable as that week's weekend.
Thinking back to the first programming course we had, this next assessment will surely be at least the same amounts of time consuming efforts so I better find myself chipping at it early this time.
When it comes to this module of the course, I usually have a hard time with new "coding" languages. Doubt SQLite3 actually qualifies, but either way. There's so much for my head that it takes a while to consume and process. I got into Larian Studios' development tools last year to work on creations for their game, and had to learn their in-house scripting languages without documentation to go by, or a mentor to trade questions with. That was rough.
Though I got through, and that is practically a second mother's tongue now, so my thoughts always go back to that when I feel I'll never get or understand something.
Vetle and I were pushing our way through Programming & Databases, diligently and fiercely working through one lecture after another, burying tutorials into the ground and scratching them off the to-do list. We had a plan. Him and I would get it done by today, so that we'd have three days to work on our final presentation video.
The fault in the plan? For the first time in all deliverables we've had throughout the first year, this one wasn't due on a Friday or Thursday. It was due a few hours ago.
We're now just hiding under our blankets in shame, crossing fingers that everything else is enough. At least it has taught us a valuable lesson to chart out deadline times ahead of time. We knew it was this week, but had made the mistake of assumptions, assuming it'd be on Friday like any other deadline we've gotten used to.
All on us, I guess. Could rationalize and argue a lot of ways, but ultimately we missed it. Two of us were heavily distracted, the other two probably had their own issues to be busy with too.
Purely for my own sake, the video would basically have been our progress report in a live format anyway. There's not like I feel we missed out on a learning experience, so in one way, we learned more from failing at noticing its deadline. That's the most positive spin I can take on it!
So, here's for inserting another coin. Hopefully it's enough with what we've got to pass a decent enough first attempt at studio, and we now know what we face and what to expect for round two.
I'm quite fascinated by all the similarities between databases here and what I'm used to from coding a video game I've been working on. The structure with x:y relationships, entities and instances have all been fairly simple to follow along with. The diagrams representing relationships in the pdf was a bit intimidating at first glance, but glaring at it for half an hour or so made sense of it, and now I'm actually considering to put some similar logic into my own planning diagrams for my personal projects.
To quickly revise what I'd answer to the 2.1 tutorial sheet. This is mostly to emphasize how I've decided to deal with tutorials; Skim through them and answer questions to myself in the head, and using that to map out what I find difficult or not to determine where I should weigh my focus at.
One to many relationships are one entity that can have many instances, such as a prison can have many inmates.
Many to many relationships is the same, but can go both ways. Such as there are many employees that can have many roles assigned to them.
An entity type would be a row in a database table representing one particular type, such as 'names' if you'd have a list of names of people, where the entity instance (or cell) would be the many, filled with names and their unique attributes.
Which kind of explains what an attribute is, a unique identifier. For example Namespace_LName to identify all last names in a coding friendly language.
Potential entity types in a restaurant could be employees, their assigned responsibilities, customers, purchases, meal types, drink types.
The the last half of March and much of April has been spent in bed, the doctors and the hospital with a terrible pneumonia and a lung bleeding from a rift from all the coughing. With that pre-context, I've had very little time to get into this course, but fortunately the course leader was willing to allow an extension.
Still, it is a shorter span of time than I would have liked to spend on the course, having a bit over a week to catch up on a month's work, and work on the assessment. I'm afraid I'll still have to cut some corners and skim through tutorials and pick and choose to work on what seems to have the most "pay-off" and work my way down a priority list from top to bottom and make as much out of it as I can.
At a first glance from the first two lectures and skimming the assessment pdf, I'm concerned I'll find this course pretty hard. Mostly because I get easily stuck up on definitions and terminologies, and the pdf was so long and from my first impressions pretty "vague". I'm gambling that it'll make more sense as I progress through the lectures.
Last half of March and the majority of April was the second most roughest month period of my life. I was struck with a pneumonia lasting a month, an atypical occurrence in my left lung, the same one that has scar tissue from an earlier tearing and blood clot. I don't really have words to express the pain and lack of ability to be human during that time. Let's just say I've been in bed for a month straight.
I'm not really sure if there's any learning experience to draw from it, other than it helps the group to keep them in the loop and informed, even when you're incapacitated, so that they know what they're working with. Turns out Vetle was sick too, and we both got an extension on the current assignment. We'll both be quite busy catching up with weeks of missed lectures and tutorials.
We're tackling that by dedicating two days back-to-back with studio to try and see how the Pi runs with the shell on it and build upon it so that it can to some extent drive around in a stable manner.
By now I believe there's a mutual understanding that we won't get to see the ideal completed Dalek we had set out to make. We never found a solution to extending the pins of the Pi to connect both the camera and the audio at the same time, and reverse-engineering the car and somehow making it able to be controlled through the computer is way beyond our knowledge. So all we can do now is "complete" it on a theoretical level, under the assumption that we could. Then scrap together the experiences we've had for a better approach in the next year's studio.
We delegated some tasks over the previous meeting, as we all agreed it's time to amp up the tempo and step up to the next gear. The last few months will surely pass at the blink of an eye. Before we know it, deadlines will push on one after another.
I'm at a bit of a loss though. Called my electrician uncle, googled to Narnia and back, but not much luck yet in regards of finding out how to connect all of the components together. We also need to deconstruct the car and figure out a way to hook into its chip and find a way to send and receive signals to control it through a computer interface.
So many unresolved challenges, and not really any particular promising approach to it yet. Hopefully some of the others in my group have some success in their research and delegated jobs.
To be fair, if I'm to think back then we should have realized. We knew none of us had experience with working with electronics and hardware. I honestly don't think that'll be our forte either. So for next year, I'll make sure that whoever I work with and I choose a project that is within our field of experience, or at least enough to have something to work from and stretch out from there into less known challenges to push ourselves.
This is going to be a short post, I just... Need to vent a bit. My closest confidant, friend and supporter died a few weeks ago. My little bird, Ori. It's a very long story, but he objectively saved my life a few years ago. Without him, it's not certain I would be here. With that said, I hope my team understands my absence these past few weeks. I've not been doing well. Better now though.
He didn't live long, not even half of a normal bird's expected life span, but he had a pre-existing condition so a full life was never expected. But he showed me how to find happiness when you seemingly have no reason to. He showed me to have fun and enjoy the small things, even on a bad day.
He could never fly, but he always soared high to me.
Turns out that a new year does bring new opportunities. Out of pure coincidence we happened to discover a local construction materials store that had OSB plates as we were looking for. Within walking distance, even. They just have a poor online presence so Google wasn't having an easy time discovering them.
Roar and I visited them in person and had a talk with some employees in the storage there, and got some recommendations. He recommended an even cheaper solution for us, which we went with. I'm not sure what the wood was called, nor does it really matter.
There's still the whole software aspect to tackle. We have some ideas for menus and how the end product may look like, but it all still feels abstract.
One personal complaint I had in the first semester was that I felt we got 'too' well along at times, making working session unfocused at times, with a bit too much joking around. Eventually I discovered that if I asked individuals to do specific things and delegate tasks around to keep them busy, work often became more focused and we could joke around in breaks.