Mohamed's journey at CSUMB

This week, I enjoyed working with shell scripting and revisiting C programming, both of which gave me hands on insights into system level operations. For shell scripting, I created a script that displays system details, checks user access, and calculates the area of both a rectangle and a circle based on user inputs. While simple, this script reinforced the power of automation for tasks like checking permissions and performing calculations. In C programming, I reviewed foundational topics, focusing on memory management and bit manipulation, which are essential at the OS level. Converting between number systems using bitwise operations fun because I have always had a hard time doing it, as it brought me back to the core programming concepts not often emphasized in higher level languages like Java. These exercises helped my understanding of OS functionality and also served as a refresher on managing low level operations that are crucial for system efficiency.

This class has been very interesting, and I’ve learned a lot of different things when it comes to databases. One of the most interesting parts of the course was exploring various types of databases, MySQL and Mongo DB, with a strong focus on MySQL. Additionally, we covered other types of databases like MongoDB, which I found fascinating. Working with MongoDB, especially using JavaScript to interact with it, was a unique and enjoyable experience. Another highlight of this class was the hands-on experience with Java labs, where we built a database system from the ground up using Java. This was extremely interesting and helped solidify my understanding of how databases interact with applications. The group projects were also valuable. I learned how Spring and Thymeleaf work together, and I had the chance to work with JDBC, which was a key component of connecting databases to Java applications. Specifically, working on connecting MongoDB to a Java application was a useful and practical exp...

This week I learned about MongoDB, and I’ve got to say, it’s really interesting, especially since I’ve mostly worked with SQL databases like MySQL and Oracle in the past. The biggest difference I noticed is how flexible MongoDB is with data. In MySQL, you’ve got strict schemas, tables, and relationships that are great for keeping data structured, while MongoDB is more laid-back, letting you store documents without needing to define a strict schema upfront. That flexibility feels more dynamic, especially when dealing with unstructured or constantly changing data. What I like most about MongoDB is how it seems perfect for modern apps where scalability and speed matter, like real-time systems or big data projects. But I can see myself sticking with MySQL for projects that need a lot of structure and consistency, like finance or anything that relies heavily on ACID transactions. Each has its place, but MongoDB is definitely cool for scenarios where you don’t want to be locked into strict d...

This week has been pretty challenging, but also really rewarding. Working with the team to get this project done wasn’t easy, but I definitely learned a lot along the way. We had to build a system to manage prescriptions, doctors, patients, and pharmacies, and it really pushed me to understand how everything fits together. We used JDBC for connecting to the database, Spring for organizing everything, and Thymeleaf to build the web pages. Usually, I’ve worked with JPA, Hibernate, and JSF in the past, so doing things with JDBC and Thymeleaf was a bit different for me. It felt more hands-on since I had to write all the SQL queries myself and manage things like transactions and exceptions directly, rather than relying on an ORM like Hibernate to handle a lot of that for me. It was an interesting change, and I liked seeing how things work at a more detailed level.  One of the biggest things I learned was how to handle data properly with JDBC.  We spent a lot of time making sure thi...

Reading   slow indexes on   Use the Index Luke was really interesting. The article goes over how indexes are designed to speed up queries and how that can sometimes cause slowness.  This doesn't happen because the index is bad or broken, but because of how indexes lookup works. When it comes to how an index work, it has the following 3 steps:  1. Tree traversal and this step is fast  2. Following the leaf node chain 3. Fetching corresponding table Following the leaf node chain and f etching corresponding tables can be slow, especially when more than one entry match the query or when the related table row are scattered across multiple blocks.  This complexity explains why simply rebuilding an index won’t solve the issue in the long run and instead  cause slower performance.