Week 30 – Multi-threading

What experience do you have with UML diagrams?

Not a whole bunch. I’ve used them before mostly as flow designs, but without any training a lot of it has been just guessing on what makes sense and not paying much attention to what the arrows, boxes or other components mean.

Are they used at your workplace?

I’ve used them at my work place before, and we include them in design documents, but again. I think most engineers are not very familiar with what each component means and how it should be drawn. I’ve seen them in far more formal settings, such as design documents from large corporations, or for big frameworks that require a bit more outside interfacing than what our in-house diagrams do.

Have you done multithreading in any language before?

Not in any real or purposeful capacity. I did very little multithreading with ruby. However, those threads are nothing like java, and the purpose of the application was mostly experimental so maintaining, or designing around it was not a concern. In other languages like Elixir, multithreading is sort of a given for how the language works (spinning workers etc), so it was not a concern before. I really enjoyed getting a better understanding of threads, and how they work. I think I’ll spend more time digging through this, and maybe writing a few more things on my own. I want to learn more about them.

Did you find Patterns to be helpful? 

Yeah. This is a pattern I am most familiar with. Most of the web-frameworks work with the MVC pattern. I didn’t have any formal education on it though. Most of it has been just professional learning through both reading frameworks, as well as reading through my peers or completing projects. Having read through the books, as well as other links on specifically java MVC gave me a better perspective. Working on the assignment, having to make the hard decision of where each part of the code goes, and figuring out how information is passed really gave me a better perspective. I think i understand better how RoR or Sinatra work and why they’ve made the decisions they did.

Update your learning journal from what you experienced this week with class. 

This week has been overall a bit lighter in some ways. The project was very complex in scope, but the I feel that after cracking how we wanted to move things around, we were able to iterate on it. Going over what the game was supposed to change, and updating the logic was interesting, but not nearly as fun as cracking the MVC flow.

To me, the real loss was the Multithreading, I really had hoped we could spend more time on it. Learning and maintaining threads, and how it can affect a program. Maybe running through multiple processing systems at the same time, like parsing files and updating the UI at the same time. So while working with the timer was interesting, it felt a bit short changed on what the real deal component was. I think we could have still do MVC with lots more of multithreading built into it.

Posted in CST-338, CSUMB | Comments Off on Week 30 – Multi-threading

Week 29 – GUI and Swing

GUI is learned late in the game with Java.  Do you think this is helpful or harmful and why?

Gosh… I think it took a while to get here. I think we should be looking into swing a lot earlier, but I also realize my team had a bit of a struggle working through it. So without a solid foundation, it’s very difficult to wrap your head around. I wish we spent more time writing swing programs, specially when you can visualize arrays or understand other concepts while also progressing through GUI portion. I would have loved to worked on small programs that are just useful in real life first, rather than this huge game that has so much logic attached to it.

Why do think that coding the Swing elements in Java would be more difficult compared to some other languages?

No clue… I have never worked with GUI’s in any serious level. I was surprised by two things about swing:

  1. How easy it is to add elements to the interface and build a working program that responds to actions.
  2. How clunky it is to add any meaningful layering of elements.

Building the functionality in swing was surprisingly easy and intuitive using inner classes, and listeners and actions. I really enjoyed how just trivial hooking a button up or displaying text was. I was also surprised how many layers, classes, nesting and management it required to get anything beyond a basic element. Once you start throwing layouts, or fonts, or any sort of meaning styling, your code explodes into this nightmare of classes elements and nesting. I would hope other frameworks and languages have learned from this, and made it easier to achieve a working interface.

Update your learning journal from what you experienced this week with class. 

This week was so much better than last… My team had a lot better communication. We worked through problems together, and made sure as a team that the program was working. I’d say of all the programs this was not only the most difficult to code, but also the most difficult to plan around. I feel the class tugs between “do what you think it’s best” and “follow my very specific instructions” which is a very tight line to walk and I do feel is a bit unfair.

On the other hand, working through swing was super fun. I really enjoyed the overall concept of the assignment though making a game in it is a big disservice to the framework. But, as someone who had maybe done one GUI in C++ many years ago, I found it incredibly fun to delve into this side of client side programing. After this, I’m far more inclined to dig a bit deeper into QT or stick with swing but give more of this GUID stuff a try at home. I bet I could create a few interfaces for my own stuff at home!

I’m actually very excited about next week. If this one was any indication, it will be a world of pain, but I have never worked with android and I’m very much looking forward to making a program I can run in a device!

Posted in CST-338, CSUMB | Comments Off on Week 29 – GUI and Swing

Week 28 – Polymorphism

This week I’ve decided to change the format a bit, and just answer the questions straight, rather than answer them in the essay format I’ve been using. Lets see how it all works out!

Give an example of polymorphism and what what be inherited between classes.

For a simple example, the constructors we have been working on are one of the definitions of polymorphism. Having a function with the same name but that takes a different set of parameters and uses Static Binding for the function resolution.

For a different concrete example, take a class such as Class Weather with a function public bool setConditions(int pressure, float temperature). If the class is extended, we may need to change those conditions to depending on the weather type. For instance a Class SeaWeather may need to include wind direction as a relevant factor: bool setConditions(int pres, float temp, char windDirection), while an astronaut using the Class SpaceWeather may only care about temperature to ensure instruments work bool setConditions(int temp).

After the learning this week, can you identify the difference between Abstract classes and Interfaces?  Be specific:

Abstract classes are classes that cannot be instantiated. They are usually used as a the base class to be inherited from. However, they can often implement common functionality, or define variables or behavior that will be used by the children classes. An abstract class is not implemented. The intention of an abstract class is often to provide a basic foundation for the children and to centralized the common functionality, and provide the minimum parameters required for all the children to work. Additionally, an abstract class can itself implement interfaces or extend classes.

A common example is a abstract class Vehicle {} which could implement things like speedUp() or have a variable int numWheels. The vehicle is just the idea to be implemented by children such as class bycicle or class train which have common functionality or implementations.

Interfaces on the other hand are not extended but implemented. Unlike abstract classes, all methods are abstract and the interface cannot have implementations of any of the methods. Additionally, any variables must be final. The main intention of an interface is to define the minimum implementation required by the implementing classes to have. It’s often used as a contract to ensure that programs know what the functionality is available. It specifies not common implementations or common functionality or behaviors, but rather the required functions that need to be implemented to honor the contract.

A common case for interfaces are database connectors, where different databases may have different underlying mechanisms to extract, create or update data. However, an interface may require that all connectors should implement the GetValue(String Key) function. A SQL connector my run a SELECT statement, while a redis connector would run a GET statement. In this case, the implementations would be very different. But because the contract is honored, a program can rely on the function to be present and work seamlessly regardless of what datastore is used.

Update your learning journal from what you experienced this week with class. 

This week has been fairly challenging. As assignments get more complicated, we also have had to look for ways to collaborate with each other, and make sure we deliver quality code. As a group, we have been trying to implement a bit more formal code reviews through pull requests. This is the first week trying it and so it will be a bit of a learning curve, but I’m hoping the small growing pain will make future projects and classes a bit more successful (I’m looking at capstone for instance).

The work however has been very interesting. I always wanted to know how QR Codes work, but always found myself a bit too lazy to find out. Having this small project does put some of this technology in perspective and it’s pretty neat solution! I’d love to do more work around the camera and and capturing real data to see how the thing actually works beyond the “star-and-space” examples we’re using.

On the other hand, I found the fact that we’re learning a little about UML super amusing, specially since I wrote about me wanting to learn it better just a few weeks ago! I still wish we dove a little deeper but I’ll settle for getting my toes wet and hopefully not making any more rookie mistakes when i have to create diagrams anymore!

Posted in CST-338, CSUMB | Comments Off on Week 28 – Polymorphism

Week 27 – Arrays and Inheritance

This week it has been an interesting challenge. This is the first group assignment, and we’ve split the work the best way it makes sense. We’ve each have tried to make sure each part make sense and tried to best keep the work both even and collaborative. One of the best and most rewarding components is reviewing each other’s code. In a collaborative project, each person brings their own patterns and styles, and even with a style guide, it still means we need to agree on what works best for the team. I think we’ve struck a good balance on that right now and hopefully it will translate to better quality code as we communicate with each other.

In the past, both as a student and as a professional, I’ve worked a number of times with multi-dimensional arrays. Normally This arrays are not very large since they represent grids in some sort. However, I’ve had to deal with graphs that span several hundred columns and rows. Rows representing user levels, and columns that represent possible attributes, combinations, equipments, etc. This can be incredibly unwieldy and they’re not easy to manage. However, they remain one of the most efficient ways to access the data.

There isn’t an specific number that makes the specifically unwieldy. I’ve found that as long as the data makes sense and the array is properly organized, the arrays can be as large as they need be. However, even a small array of a dozen elements, that offers no predictability can be a disaster of a structure. I’ve found that it’s best when arrays don’t have gaps.

On a different note, inheritance is in great part the foundation to web development. Frameworks like Rails or Sinatra in ruby, or Leaf for PHP rely heavily on inheritance. To me, it’s both the hardest part to get right, but also the most useful. Proper abstraction can make a framework easy to use, and powerful. But in my experience I personally tend to get bogged down on the details, and either over abstract (trying to solve every problem on the parent class), or simply leave the full implementation to the children which defeats the purpose. which is what i’m most familiar with.

This is certainly one of the goals I’m hopping to reach by the end of this class. I want to at least get the proper foundations for this basic concepts. Some of it comes with experience, but it’s also very important to highlight the theory.

Posted in CST-338, CSUMB | Comments Off on Week 27 – Arrays and Inheritance

Week 26 – OOP

Weekly Learning

This week we continue learning Java. Again, it’s a week were I’m trying to battle between what I am familiar with (weakly typed languages), and what we’re learning. I really like the immediate feedback of typed and compiled languages, and it’s something I had seriously forgotten about. There are small details on the implementation that make it frustrating at time: For instance, the fact that '' signifies a character while "" signifies a string. They’re minor inconveniences for the predictability and structure that typed and compile languages offer.

I also have to work on some of the older habits that I’ve acquired. For instance, throwing outputs around all over the code. On web development this is normally ok since they go to a logger, and they serve as checks in the code itself rather than for the consumer or costumer. But in a console driven program, or an application that requires the program to communicate with the user, the placement of the output, and the structure around is actually very important. These are good habits to learn and keep.

I have used a lot of OOP in the past. It really makes up most of my experience. Functional programming is portion big enough to understand and appreciate the different paradigm. I have always liked OOP, though I think functional does solve a lot of interesting problems in a more efficient way. However, it seems to start getting overly complicated when solving large issues, where objects can maintain a simple structure that can be extended. OOP is popular because it’s both flexible, accessible and efficient at solving problems. I’ve found working with both, that code in OOP is often more readable, and while there maybe a bigger mental overhead per function, there is a lost less for the program as a whole since objects and their structure can often be blackboxed.

On the other hand, UML has always been difficult for me. I can draw simple diagrams, but I have always felt unsure on how to properly break down the structures and how each step should be represented or the depth and detail of the diagram. I think I did a decent job for my video, but I personally would like at least a small workshop on that specific topic. I feel they’re incredibly tools that when done properly can convey the entire message with little to no mental overhead. But they’re also rarely used properly.

I hope we get to work a bit more with those tools. Part of having a proper program in place is to have technical documents behind it. Writing that sort of documentation is a skill all on its own and its something schools should also work to teach students.

Posted in CST-338, CSUMB | Comments Off on Week 26 – OOP