CST 499 Week 7

This week, we worked on the Capstone video. I spent a majority of the time working on text to speech using Google Cloud. I tried Java since we used it for the past 2 classes, but I couldn't get the dependencies to work and it would not run. I then followed a tutorial using C# in the in browser terminal and code editor. It was clunky and strange but it was able to run the sample. I could not figure out how to enter text in the terminal then run the code.

Now that I understood that it did work on my machine in some way, I decided to try Python. It has been awhile since I used Python but it's simple enough and easy to install the dependencies since its only one pip install line. I downloaded the entire text to speech library from the Google Cloud github since the sample code was helpful but not as in depth as I wanted it to be. Using the examples, I was able to write my own functions for it to do what I wanted: allow me to input text, not delimit it based on newlines, translate it to ssml, and modify the voice and pitch used. I like Python's ability to be simple and easy to write, but it reminded me of why I dislike Python; writing for loops with iterators is awkward. In Java it's easy, in Python its different in a bad way.

This Summer, I hope to finish off the CTI technical interview questions I saved from last Summer. The wild thing about this all is the sister school, El Camino (along with CSU Dominguez Hills) Community College, is from my hometown in south LA, where my sister and I both took classes. My High School, Junipero Serra High, is down the street from there and this CTI program combined with the Warrior-Toro CS cohort pathway program will have a huge impact on the largely underrepresented minority students who go to El Camino from Serra. I also read in the HS newsletter that they even started a coding club. It's all very exciting for my former high school and the great opportunities those kids will have.

CST499 Week 6

This week, we took the ETS test and worked on the video for the Capstone Festival this weekend.

We worked on writing a script last week, a Google Slides this week, and incorporated the script into the slides. There was a lot of information to cover but we will hopefully get it all done in max 7 minutes as the guidelines state. It seems like the demo video included an app as well as a website so theirs was an entire 9 minutes which we aren't given. I think it would be a better experience if we have a short video for the capstone and a longer one for our portfolios so we can explain as much as we want for at least our own personal records.

The ETS test score was lower than I expected, but it was a difficult test. I knew how to do a few but guessed on the majority of them. I don't feel like the material covered had that much to do with my career going forward. On Glassdoor, interview questions are posted and they usually aren't as extensive. If anything, focusing more on the Technical Interview or my Portfolio would have been a better use of my time.

CST 499 Week 5

This week we continued working on our project. Initially, I was working entirely in my own Github branch. It was many commits behind the master branch. I thought I could merge them all later, but that creates a lot of problems. This week, we worked more with the Github Issues project management feature where we assign ourselves tasks and then use pull requests to merge in to the master branch after they are reviewed. This system works for me and makes a lot of sense for everyone involved.

I also worked this week on learning how to branch, reset head, add, commit, checkout, and push to master with only the command line. Before, I only used the Github for Desktop app which I have had decent luck with. Then I had problems with merge conflicts and instances where I needed to reset the head of the branch but didn't have any buttons to do that. This prevented me from pulling from the master and using the command line makes it a lot easier. I still use the Github for Desktop app to check if changes have been made in a easy to see way.

CST499 Capstone Week 4

This, week we worked on our capstone project. I didn't get as much done as I would have liked, but I learned about a few interesting topics.

My goal was to add a license in a textfile to a window that could be closed by clicking off of it. I tried a few different approaches like linking a text tile to a Text object, then attaching that to a window or using a scanner to read in every line. In the end, those didn't work, and I created a very long String, called that class and function and printed it out to the window. There are some inconsistencies, but its functional.

I later created a mouse event to close the open window when it was clicked on.  As a result, it meets some of the requirements we initially planned, but not all. 

Another problem I had was that the window was too large initially, so I used several functions to get the window dimensions then create a viewing window of that size. This will most likely work on other's computers as well.

Next week, I hope to get a lot more done and ask for help when I need it.

cst 499 Capstone Week 3

This week, I focused on FXML and Menu bars for JavaFX. FXML is an XML based language that lets the user build a GUI without application logic. First, you make the main class and define the stage and scene. Than you change the import statements in the FXML file to include what you intend to work with. The elements the FXML file deals with can also be done in a .java file. FXML files are a little bit cleaner and it is easier to see what elements are nested. JavaFX can also use CSS to add style. In the JavaFX specific CSS, not every CSS statement works without issue. There are some limitations to its CSS abilities. When I was using Eclipse, with a few JavaFX plugins, there was still no JavaFX CSS specific help offered with code completion. Overall, JavaFX is a great way to make GUIs and I would definitely use it in the future.

cst499 capstone week 2

This week, our group discussed the effective meetings reading from last week. It seemed like we already used a few ideas in the article through our CS learning. A number of meetings could have been done over email and didn't need to be discussed. Meetings are nice to have in general, just so everyone can get their input in all at once. We used to keep minutes but every big decision was later posted to the Hangouts chat to remind everyone later. It was concluded that this article was not software development specific because as we have read about, failure in software will happen. Deadlines can be missed and features could be implemented incorrectly, it is not unacceptable for this to occur. Features that take longer than expected is built into Agile's point design. I haven't worked in a professional software development setting, so I will have to see for myself if the tips in the article work. 

cst 499 capstone

This is a summary of how to run business meetings that produce results. Before every meeting, plan the meeting, ensure the necessity of the meeting, ensure participation, and distribute pre-work. Before a meeting is planned, plan a pre-meeting with others who will help you plan for the meeting, then decide if a meeting is necessary. After you decide who needs to be at the meeting, postpone the meeting if essential participants are unable to attend. 48 hours before the meeting, send the reading material to every participant so they are ready to meet. 

During the meeting, facilitate the meeting, involve each person in doable actions, and create a follow up plan. The meeting leader should keep the discussion on track and ensure the meeting meets the meeting goals. The meeting leader should involve attendees who aren’t participating because sometimes people take time to think through their answers or will only respond if there’s a consensus in the room. A follow up plan with action items, name of person with action item ownership, due date, and definition of a complete action item should be made.

After the meeting, publish the meeting minutes, follow up, create accountability, and debrief meetings for improvement. The meeting leader, secretary, or note taker should publish the meeting minutes and plan within 24h. Then follow up with people between meetings. A culture of accountability should be established by making failure to keep commitments unacceptable. Lastly, the meeting leader should have participants discuss what was good and bad about the meeting process anonymously because you won’t get real answers otherwise.