Arlon's CSUMB Java Software Design CST-338 Module 5 Learning Journal 13 for the week Wed 03/31-Tues 04/06, year 2021

Prescribed questions:

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

It's super tricky to write a GUI program without console. Think beginning PHP with a broken page when you haven't learned file output yet. It's tricky to see what's going on. So it's real helpful to have some sort of console output, even for GUI programming. There's questions you need answered - you put them into the console. GUI programming can make a GUI for testing output, too, but it's really helpful to start with console output. So I think it's more educational to learn console output first, because it's more natural you wouldn't really learn GUI programming without learning console IO first. So I guess the answer to the late in the game question is - helpful.

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

I don't necessarily think that. Swing's pretty easy. That's why I picked Java as my first programming language when HyperCard died.

Here is some Python with Tk component initializer code I wrote about 11 years ago, it uses the linearity paradigm I'll talk about below and looks real similar to swing, if not similar, at least reminiscent:

   def initialize(self):
      
      
      self.grid()

      self.entryVariable = Tkinter.StringVar()
      self.entry = Tkinter.Entry(self,textvariable=self.entryVariable)
      self.entry.grid(column=0,row=0,sticky='EW')
      self.entry.bind("", self.OnPressEnter)
      self.entryVariable.set(u"Enter text here.")

      button = Tkinter.Button(self,text=u"Click me !", command=self.OnButtonClick)
      button.grid(column=1,row=0)

      self.labelVariable = Tkinter.StringVar()
      label = Tkinter.Label(self,textvariable=self.labelVariable, anchor="w",fg="white",bg="blue")
      label.grid(column=0,row=1,columnspan=2,sticky='EW')
      self.labelVariable.set(u"Hello !")
      
      canvas=Tkinter.Canvas(self, width=600,height=600)
      
      self.board_click_mode="auto_blacks_turn"
      self.whites_score=2
      self.blacks_score=2
      square_x_1=5
      square_y_1=5
      square_x=square_x_1
      square_y=square_y_1
      side_length=70
      square_s=side_length
      spacer=2
      self._start_click_x=0
      self._start_click_y=0
      self._end_click_x=0
      self._end_click_y=0
      self._now_dragging=0
      self._oval_clicked=0

More Journaly Stuff:

I'm sure everyone knows this but I like writing about programming, so, just to talk about how I like to write programming, in Java, From this weeks programming assignment, phase 1 instructions - and also very commonly in Java tutorials, there is a paradigm listed like:

JFrame frmMyWindow = new JFrame("Card Room");
frmMyWindow.setSize(1150, 650);
frmMyWindow.setLocationRelativeTo(null);
frmMyWindow.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);

// set up layout which will control placement of buttons, etc.
FlowLayout layout = new FlowLayout(FlowLayout.CENTER, 5, 20);   
frmMyWindow.setLayout(layout);

// prepare the image label array
JLabel[] labels = new JLabel[NUM_CARD_IMAGES];
for (k = 0; k < NUM_CARD_IMAGES; k++)
   labels[k] = new JLabel(icon[k]);

// place your 3 controls into frame
for (k = 0; k < NUM_CARD_IMAGES; k++)
   frmMyWindow.add(labels[k]);

// show everything to the user
frmMyWindow.setVisible(true);

		

I'm sure everyone knows this because there are lots of ways to do it, and this way works great, and is really clear, for it's linearity.

As a beginning Java programmer, 21 years ago, I was slightly confused, I remember, at first, by the paradigm, and now I think I know why. It's fine, but now I like to do this with an anonymous and hierarchical paradigm wherever possible. I feel like it is more logical and elegant to utilize a more hierarchical, anonymous paradigm when I can, something more like:

new JFrame("Card Room"){{
  
   setSize(1150, 650);
   setLocationRelativeTo(null);
   setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);

   // set up layout which will control placement of buttons, etc.
   setLayout(new FlowLayout(FlowLayout.CENTER, 5, 20){{/*Adjust the flowlayout here!*/}});
     
   // prepare the image label array
   JLabel[] labels = new JLabel[NUM_CARD_IMAGES];
   for (k = 0; k < NUM_CARD_IMAGES; k++){
      labels[k] = new JLabel(icon[k]);
      // place your 3 controls into frame
      add(labels[k]);
   }
   setVisible(true);  // show everything to the user
}};
		

It's the same, in essense, but the JFrame is anonymous, so is the layout, and the mods to them are inside them - this is good for encapsulation, clarity, neato-ness, and it just makes sense that the JFrame should do everything it can for itself, if possible, and if it's not going to be referred to later, why name it. For example the name layout is used exactly once, and that used to confuse me reading examples because until I could read Java easier, that almost seemed like a built-in Java keyword or something. Even in context in this and the previous sentence, it should almost have single quotes around it - you almost have to read the sentence twice to realize layout's a name. There's lots of reasons to name things, if you do want to refer to them later, but you don't always need to. I'm not complaining about the examples, I just like writing about alternative paradigms.

Besides, I'm sure here we are learning how to design, but not necessarily perfectly, so that then, later, we can see the contrast of how to design with perfectly structured paradigm!

I can't figure out where I read it, now, but I read in the instructions, for one of the assignments that you should not change random things to see what happens. I disagree with this tip for a few reasons. Why not? Breaking stuff on purpose is often a helpful learning and research tool. And it's hugely fun. Lets see what we can break.

I think it may be bad advice to tell people to not just change whatever they want. Why fear your own program, or the compiler? I say have at it! There's always undo. If the software doesn't have undo find a software that has a good undo. I mean if you're trying to achieve a specific bug fix - guessing - well even then - sometimes guessing is one way. It's not always the final way, but it takes a stab at the issue and gets you going on the question.

Undo-redo also double as a work-history documenter and triple as a where-was-I-just-now-recent-work-finder.

Here is a good example of trying stuff that might not work - when I was working on this week's card game Java with Swing programming assignment - you get the GUI "done" only to realize there's a bunch of invisible borders around everything aligning everything - so then you do the borders. At one point, toward the end of matching the layout, I started getting it figured out, needed to add spacing to the titled borders and found createCompoundBorder() in the API for javax.swing.BorderFactory. I threw a guess out at how to use the method - just threw two borders at it - and the compiler said I was right! It worked!

This design for these card games - I think it is known - that it is designed to accentuate bugs. So that's fine, since we're beginning. I'm talking about putting the cards in an array instead of an ArrayList and all the MAX_CARDS and numCards - all the built-in limits - all that's just asking for bugs, when, in real life - and later on in the class maybe, or other classes - we can just use an ArrayList and nip the limit bugs in the bud before they rear their ugly bug heads. And later I am sure we will learn how to write in a much more general fashion to remove almost all the built-in limits in the program. Those are just there to teach us how to deal with legacy code, debug, get us going programming. But they look - and I think they are intended to look this way - like programs I wrote when I was still learning to design correctly, but still didn't know how to, quite yet.

Also I'm sure it's known that the examples are contrived as far as how they work - since we're just beginning students. Generally speaking, programs have public hooks you write in to be able to use them - the examples are contrived here - I'm sure this is known - just discussing it.

For example Here's a quick example: in assignment 5, phase 2 main is supposed to say:

CardTable myCardTable = new CardTable( "CardTable", NUM_CARDS_PER_HAND, NUM_PLAYERS );
myCardTable.setSize( 800, 600 );
myCardTable.setLocationRelativeTo( null );
myCardTable.setDefaultCloseOperation( JFrame.EXIT_ON_CLOSE );

A real program would do all that stuff for itself, not leave it to main to finish off. One way would be to use the anonymous paradigm I discussed above, another way would be to put the stuff in CardTable where it belongs in this case, I think. I think this is this way just because this is a pretend spec. A real spec would have a real program and real need to slightly modify it later. So it's fine, I'm just saying I can see the contrived-ed-ness of the assignment, and that it is, causes it's design to be inherently less good. It's totally fine for beginning Java students I think, especially if a contrast is demonstrated later. But I definitely wouldn't label this design as a particularly great design the way that it is. That's how many of the tutorials are though, too.

Team work is important, I really don't try to knock it but I also think team work applied correctly is more important than just smashing people together and trying to get them to necessarily agree on a program - even corporations know the famous quote by Frederick P. Brooks "What one programmer can do in one month, two programmers can do in two months." That's why corporations that use teams have a hierarchy of regulating personel so the teams don't just misfire and create garbage.

Look at AccountBlaster, and then tell me I need help from a team in completing a programming project. What I need is help from a marketing department and HR to hire the marketers. Oddly I'm actually pretty good at marketing too, but I'm not even trying to develop that skill, just compensate for the lack of marketers in my life. That's exactly why I also know plumbing, boat maintenance and repair, car maintenance and repair, home appliance maintenance and repair, how to run a home business and everything else a do-it-yourself-er normally knows how to do, and more. I can blow glass, weld, solder, design and create weird electrical things, switches, fix everything, write computer programs that do whatever you want them to do, which is my favorite skill for some reason, I think because of how programming is so thoroughly logical, and how much you can create very useful, incrimentally useful tools with it. You can make something, that helps you through something and then build off that, and make something great.

I replaced a dying game, made it spectacular, feature rich, and had players around the world at my game, it was very popular, world wide, in Othello circles, it was it's own Othello circle, for several years. You can only do so much with plumbing. I think electrical engineering and robotics are two other very interesting fields though, that I don't know enough about, yet. But what about real estate sales? I know so many realtors and - it seems like all they do is make stuff up and make tons of money. It makes me wonder - because I know more than most of them about real estate too, being an appraiser for almost as long as I've been a Java programmer, maybe 21 years or so.

I wrote extremely helpful - essential - to me - appraisal software for myself, AppraisalBlaster, which does - a lot - more than it's commercial counterpart, DataMaster - and obviously has a 100x cooler name! Not that it's better just because of the name - I'm actually the appraiser too - and - DataMaster doesn't do a lot of very important stuff that my AppraisalBlaster software does do. I know, because I'm the appraiser. That's my software beating an entire corporation out - feature-wise - and cool-name-wise- and to myself - helpfulness-wise - and potentially to other appraisers - helpfulness-wise as well. I don't quite have the ability to market it to other appraisers because security features aren't present yet, but that is definitely a strong potential for it, with just a few more feature additions to compensate for what the implications of sharing it would be.

And AccountBlaster is marketed - sold - released - useable by all - everyone in the world - it could take over the world tomorrow for all I know. I created it it's own marketing pyramid - so once it catches on - marketers will buy into the sale discount capability to sell more marketing tickets for more marketers to sell discounts - discounted marketing positions - and discounted AccountBlaster subscriptions. With a never-decreasing price I am hoping there will be an incentive to maintain subscriptions through time. It is free for all but just with the slightly annoying feature that you would have to save and restore your work every couple of minutes to keep it from 'morphing the numbers' by a tiny percentage - $100.00 becomes $100.01 etc., or, people can save and restore every few minutes - hit F5 to refresh the page - and it's a built -in intentional hack I gave it, so it's also freeware. Freeware with paid incentive and a built-in marketing pyramid, all with a supporting Drupal website to host and back it.

As soon as I fix my Rodeo, which is sitting in my yard with busted freeze plugs and an oddly frozen clutch, next I'm going to fix my game, too, so I can start bragging about it again. This was what it looked like, with two windows of it open:

[Super Bomb Reversi Screenshot]

Thanks for reading!