Friday, January 9, 2015

Java StopWatch: making the buttons move

Making textbox output is a bit of a pain, but it's not that terribly hard.

Here's a picture of the design for reference.  I still need to figure out how to center the items in the GridLayout().


I ended up writing a separate private subclass to implement the minutes up button.  So...  how does it work?

You start with a string as the current text box output.

String txt = minutes.getText();
char characters[] = txt.toCharArray();

Now, I could probably cram this on to one line, but I don't think I am.  I like the simplicity of the statement, and it's not that complex or hard to understand.  

So, now we've got a character array holding what is displayed in our minutes field on screen.  Where to next?  

I need to convert those to integers.

int ones = characters[1] - '0';
int tens = characters[0] - '0';

Simple enough?   Take whatever the unicode letter is and subtract it from the unicode character '0'.   Simple math, and then you have the ones and tens place.

As a side note, I learned the last bit back in 2000 when I was learning C++.  I have since fallen out of use in C++, but I still remember that trick to get a number out of a character.

Ok.  Now we know what our number is.   We need to increase it.  

Simple enough.

ones = ones + 1;

if(ones >= 10)
{
     ones = 0;
     tens += 1;


Easy enough to understand, I hope?   + 1 to the ones place.  The ones place can't be greater than 9, so if it gets bigger than or equal to 10, then make it zero and increment the tens.

That will give us a stop watch that will increase up to 99 minutes.

And for the final bit, pushing the new number back into the JTextBox

minutes.setText( Integer.toString(tens) + Integer.toString(ones));

After the rest of the complications, this one is easy.

I haven't written the code for converting seconds, but that is also simple enough.  The only question is what you do when you reach 59 seconds.  Do you go back to 0, or do you increase the minutes by 1 and go to 0?  

Either way can be done.  It's just a personal preference.  Generally, I count up minutes and seconds.  Though come to think about it, I count up every time and only could down seconds.  So my program is inconsistent.  I think with this one, I'll just make the seconds rotate.  It's another simple if/else comparison.  

But yeah, that's about it for the up buttons.  For seconds, just swap a few names.  The down arrow works pretty much the same way, except it decrements.  

As a random thought, I have thought about trying to cram the minutes/seconds up buttons into one class.  I'm sure it's possible, I just don't have the skill.   Essentially, both would have to have a separate actionPerformed, and I'm not sure how to do that.  


Thursday, January 8, 2015

A bit busy

Can you say busy?  Yup.  It’s been.  It’s been the good kind of busy, though.  I spent a few days building a new Active Directory Group Policy.  Default templates work well, but they still need tweaked.  Not everything works out as well as you’d think.  Or at least not always.

I’ve been contemplating security in depth, and I’m pretty sure my old beliefs about security are still true: security is an illusion we like to tell ourselves to ignore reality.  It really is.  Several companies I’ve dealt with are completely clueless as to what they do and how they operate.  They are no more aware of their failings than the man in the moon.  It’s moderately hilarious, but only in the sick, sad sort of way.  I guess there is always a need to upgrade and move forward in a technology related company.  The inertia of doing nothing often gets in the way of real accomplishment. 


I think that will be it for today.  I spent a few minutes working on the Java StopWatch, but not enough to do anything of interest.   Yay.   I have large letters and I set up a font.  But they aren’t centered in the boxes so they are kind of ugly.   But at least the numbers are large and readable.

Wednesday, January 7, 2015

Chemical Bombs / Games Theory / Candy Crush

Last night before bed I was contemplating Candy Crush.  I’ve played the game a lot before, and yet I can’t ever seem to say anything nice about it.  And yet, I continue playing over and over and over again until my lives run out and I’m told I have to go sit in a corner and wait.  And at some point, I come back and do the same thing over again. 

Why do I do it?  What makes me continue to play a pointless game?  Why do I continue playing when I can’t think of a nice thing to say about it? 

Better yet, how can I replicate that to create something that teaches?  I’ve messed with quite a few learning games before, but most of them are pretty much the same thing.  All of them allow you to participate as much as you want.  I think the scarcity mentality of the game is really what makes the game. 

I grew up on Super Mario Brothers.  We’re talking back in the in olden days when Nintendo and Sega were fighting like cat and dogs.  I had a Nintendo in those days, and my brother and I would play Super Mario brothers for hours.  And hours.  And hours.  At points, the game grew excruciatingly painful to play.  Certain sequences were just nightmares.  But eventually, through a combination of luck and skill the level could be defeated. 

The biggest thing about the game was its scarcity mentality.  There was a point in the game where it didn’t matter how good you had done the previous times, it was over.  When your lives ran out, it didn’t matter that you played for 30 straight hours.  It was over. 

And I think that scarcity mentality is part of what makes Candy Crush enjoyable.  If Candy Crush could be played for hours on end, it probably wouldn’t be played as much as it is.  But the scarcity mentality of only having a few lives makes the game slightly more interesting. 

Maybe I’ll turn it into a chemistry game called Chemical Bombs (a slight joke on Bonds) where you use a limited set of the periodic table to create balanced chemical equations.  The tiles would be the periodic table times, and the goal would be to create chemical bonds and create…  something.  Maybe several neutral equations, and seveal that were negative and some that were positive.  I think that depends on the level. 


Seems like a good idea to me…   

Tuesday, January 6, 2015

Program 2: Java Stopwatch

With the NetworkStatus application in a mostly working state, it’s time to shift gears to a separate application.  I like to build small, similar applications that will eventually use the same basic ideas.  The first application was designed to get a button working and responding to being pressed.  Program two is about threading.

And what better way to move to in to threading than my old favorite of the threading world, the Stop Watch.  StopWatch will be of similar design to NetworkStatus.  The thing would have several buttons allowing you to adjust the time, and display in the middle of the screen.  There should be a start and stop button.  So I guess the first thing is to pull up paint and create a generic mockup of the program design. 

I decided to go with a 3x4 grid layout simply because it’s different than the gridbag layout I went with earlier.  I’m still not impressed with Java FlowLayouts, and GUI design in general seems like a real pain.  But I’ve got to learn to work with what I have to work with.  Some systems just seem to be better suited for certain things than others. 


The number in location 0,1 and 2,1 will be independent of each other.  They will be separated by a colon.  The colon ends up being just a text field with the text size increased to make it look pretty.  Really, the 0,1 and 2,1 are text fields as well.  They will just be handled with some special code to make them operate properly.  It’s not complex code, and I’ve written the same thing in other languages before. See my C# example below.


Though after examining my old C# stop watch, I might put a reset button in the middle.  That could work out nicely.  So, half an hour into this project I have a reasonable (though ugly) facsimile of a StopWatch.  It is not fuctional, and I need about 200-300 more lines of code to make it work without threading.  But at least there’s been some progress made.  Maybe tomorrow, it will be counting. 


Probably not.  It will take all of tomorrow to get the buttons working properly.  

Monday, January 5, 2015

Working solutions

So it looks like the basics are working on the program. Now that it does what it’s supposed to, it’s off to creating the not so easy portion of the system.  There are still some minor portions or the program that aren’t working properly.

The answer to the initial question was…

this.setVisible(true);


Guess it was the simple stuff that was causing things to fail.  It almost always is.  The next question I’m wondering about is the scroll bar on the text box.  I’m sure it’s something easy, but easy isn’t hitting on the head right now, I’m going to have to keep guessing. 

The other items I’m wondering about are all style issues.  Simple things like why there is so much gap between the top grouping and where the list box starts.  I shouldn’t call it a list box, but that’s what it reminds me of.  It’s really a JTextArea.  

This is what often happens in many of my programs and projects.  I break down to fighting simple/stupid stuff that doesn’t really equate to how the program operates.  It’s just a visibility/design issue.  But design issues can make or break a program.  Certainly, there should be more to the program, but at the moment, everything seems to be acting like I think it should.  As a test, it works well. 

The next questions are all technical ones.  Such as, the InetAddress.isReachable implementation.  I question these things, because the creation I’m thinking of making is some sort of thing that examines the current state of hosts imported through an XML file and alerts based on whether hosts are reachable or not.  It then checks every 30 seconds or so and writes the information to a database.  From there, you can see the long term uptime of a network.

And I really want to know what it does and how it operates, because proper troubleshooting requires knowing why something is doing what it is doing.  And really, you need to know both what the results tell you and what the results don't tell you.  I've spent 3/4 of a day fighting an Internet issue because I quit listening to what everything was telling me.  I was being too quick to jump to conclusions. 

There are other things I’m contemplating, but I don’t know how to implement them.  In the end, almost all of my programs become horrendously ungainly things where feature creep becomes a dominant factor.  Well, feature creep and general GUI design flaws.  Like I said, I spend a lot of time fighting GUI design.


Other than something I wrote in C# that checks to see whether a collection of backup files are there, and the date on those files.  It then emails me, telling me whether things succeeded or not.  But that probably needs updated just to make sure it stays working.  Or,  I need to rewrite the entire thing in Java.

Friday, January 2, 2015

Java layout managers

My reference on all of this has been Java All-In-One for Dummies.

I have a feeling Java layout managers are going to drive me up the wall.  It’s strange, but if I get things just perfect, all the items display on screen.  And if I don’t, nothing shows up until I resize the screen.  Strange to say the least.

I spent a while fighting with the flow layout, but that wasn’t doing what I wanted.  Towards the end of this session I decided to move towards a gridbag layout.  I have to admit, I like the idea of what gridbag presents, but I’m not sure it’s going to do what I want it to.  Fighting miniscule stuff like this is really annoying.  I think that is part of the learning curve, and the reason I wanted to program every single day.  There are some things that are only learned through blunt repetition.  I’m guessing this is one of them.

I was planning on implementing a text area to deal with the output from the text box, but I haven’t made it that far.  Fighting the layout manager took more time than I expected, but eh well.  Yeah, it’s ugly but it’s starting to be functional.  The button will work when the code is written to handle it.  I tested it a few days ago, but I’ve since changed the code. 

The program itself has been redesigned slightly.  I was intending on settings up the button as a separate class, but in the end I had to get rid of that idea.  It because a private inner class of the display class.  I guess I should have known that from all my Visual Basic work, but meh.  It’s been a while since I touched Visual Basic. 

I have to admit I’m making decent progress faster than I expected.  I’m okay with that.  Fast progress on programming shouldn’t have come as a surprise to me.  Once you’ve learned one language, it’s a matter of learning syntax and what can and can’t be done in the language. 

Java does seem to be the predominant language of the day, and that’s the reason I decided to learn it.  Everything else still exists, but seems to be lessening in many aspects.  That’s just a personal opinion of mine, and based on no known fact or discussion.  Just vague observation.  And  I could be completely wrong.


Thursday, January 1, 2015

More on Java

Back to Java.  I was working on writing a test servlet application to run on the new (really old) computer, and spent some time fighting NetBeans until I figured out what I needed.  What I was missing was the entire javax.* import information.  It was under Tools->Plugins.  Despite my best attempts, it’s still not working as I write this.   The Javax import is there, just not the servlet portion.   I will fight that later.

I think I learned a bit that I’d forgotten in my rush to get an app together.  The idea was good, but the idea was a little more complex than my mind could really wrap itself around.  Learning any new programming language generally requires spending a certain amount of time building junk programs that do little things.  Most of those programs aren’t really good for anything except building a bit of muscle memory and learning.

I think I also took a step back with the realization that I need to grind out a few programs here and there and make something work before I try something I want to sell.  If I can’t write the code for what I want to do in Java without having to fight Eclipse, or any other IDE, then I don’t need to be trying to write the code.  Because there is a knowledge gap, and that knowledge gap becomes obvious when you start developing more complex applications.

So I’ve decided to spend a bit of time every day developing junk applications.  Things that might be useful to me, but are otherwise useless.  Maybe the simplicity of a button class that realizes whether a Boolean has been switched.  Really simple, stupid stuff.  But then, opportunity often comes dressed in coveralls and looking like work.

Because, despite my best interests at self-sabotage, if I read 11 pages per day for the next year, I’ll be done with my 5,200 page sprint through physics, calculus, and artificial intelligence.  And when those 11 pages per day are done, it’s time to start practicing to perform.  But there has to be a sufficient knowledge base reached before I can even begin to put that sort of knowledge into play.


To put it simply, I should have the ability to design a user interface that looks like what I’ve imagined before I try and develop something that can think.  I shouldn’t be wondering how to program a button so when I click it the thing starts to work.