Showing posts with label Java. Show all posts
Showing posts with label Java. Show all posts

Monday, December 20, 2021

A bit more Java here and there

 Some days, the cost of code is crazy.  The ability to build and code solutions to problems is not something everyone has the capability of.  But then when you see how little code it can take to solve a problem, you realize just how expensive code can be.  


With a bit of messing, I figured out how to write an event messenger in Python to handle a built in system integration.  It took me about 300 lines of code.  


Funny thing: a few weeks after I figured it out, a vendor offered me their solution.  For $15 per month, per site.  I kindly told them no.  At 20 sites, that's about $1 per month, per line of code.  Which is pretty nuts to say the least.

So I moved on, and decided I wanted something a bit more permanent.  My code runs as a nohup process on an old Ubuntu box that is acting as a syslog receiver.  Which made me think: why can't I write my own syslog receiver?  


Nothing really prevented me from doing it, but I didn't have a decent IDE in order to do what I wanted.  I've used syslog collectors from SolarWinds and Graylog.  Both were functional for what they do, but that don't do what I want them to do.  Alerting is part of it.  Data collection is another part.  But there's so much more that I think should be and could there.  Somehow that blend of SIEM and syslog collector always seems to appeal to me.  That gathering of "EVEN MORE DATA".  And I do understand that more data doesn't necessarily mean better decisions.  It just means more data to sort though.  And the need for more algorithms that handle that data, so the alerts generated off that data can be reduced from the thousands to individuals.  


But like I said, no IDE.  Microsoft makes a good one, but it's not free.  I like Visual Studio.  I just wish they gave it away for free until you get to a certain level.  Like the SQL Express model.  So I quit using their stuff.  And I moved to Eclipse.  


Eclipse is pretty decent.  The autocomplete makes me mad here and there.  But it's functional, and it allows me to build complex, multi-hundred lines of code applications.


Like my syslog collector.   That I finally wrote in Java.  

And that's about all it does right now is collect syslogs.  But I've got plans for that sucker.  Because eventually I'm going to take that 300 lines of Python code and turn it into Java.   And I'm going to attach a SQLExpress database to it, along with an IIS front end for a web application view of the mess I'm creating in the background.  Why?  Because I like web front ends.  

And because I want to learn more about SQLExpress and IIS.  And that's generally a good enough reason for most of these projects.  Or at least I think so.


Thursday, July 30, 2015

More Programming

So.  After a bit of time away, I finally had some time to work on programming.  I’ve been working on the idea of a program that teaches speed reading.  Essentially, the goal is to present words to a sentence faster than the subject can normally read.  Sounds like a great idea, right?  Except that Java isn’t really a real time system, so getting threads to sleep for 240 milliseconds just doesn’t work.  That would equate to 250 words per minute reading pace. 

What I end up getting is entire lines of the text, in speeds that are considerably less than 250 words per minute.  Though… a little messing and reading made me realize my conversion factor was off.  It seemed like the answer should be…

(1000 milliseconds X 60 seconds) / (word per minute pace)

I revamped the equation to take a different method.  I think I was running into too many float to integer conversion errors.  Or at least that’s what I’m going to blame. 


But it looks like Java can’t do that kind of precision in waiting.  Googling lead me to a lot of the same answer.

If the speed is slow enough then the pacing works correctly.  But it looks like either 1) Java isn't capable of printing 1 piece of string at a pace of less than 300 ms, or 2) I'm not a capable enough programmer.  

So, that's that.  Perhaps it's time to go back to looking at C++.  

Saturday, April 4, 2015

Speaking of Java and MySQL

So, I finally got my Java/MySQL connection working.

Hooray!


https://help.ubuntu.com/community/JDBCAndMySQL

Was where I learned to fix the "class not found issue".

After that, I dug up http://www.tutorialspoint.com/jdbc/jdbc-quick-guide.htm to get instructions on how to use/connect to the database.

Afterwards, I was capable of spitting out information to the system console from the database.  Holy crud!  

Definitely making progress today.

Yay.

Wednesday, April 1, 2015

The first two hours

In trying to program 10,000 hours worth of stuff in Java, I realized I was going to be building a whole lot of stuff.  After two hours, I’ve finished the first program.  It’s a translator that takes CIDR notation information and turns it into Snort rules.  The entire purpose is to block entire countries.  The problem is countries are large and have a lot of IP addresses.  Blocking China takes a few thousand lines of CIDR notation.   And aggregate it all into smaller routs?  Highly unlikely.  So you end up with 3,000 lines that you can either manually parse through or write a program to parse through.  I chose to write a program. 

And I’ve also come to the realization that in the run to get 10,000 hours, I’m going to program a lot of stuff.  That is a lot of time.  At 30 minutes per day, that’s 54 YEARS.  So at some point, I’m definitely going to have to put in a lot more effort than I currently am.  
 
So now that the Snort builder is done, what’s next?  Probably moving back to my automatic network test application.   Which is mostly writing text parsing.  From there, I’ve got to figure out how to design a database structure and get the information into a database.   From the database, I have to get data into a web form and display it on a web server that doesn’t exist. 

Just a slight bit complicated, but I’ve got nothing but time.  

After that, there's a SHA application I've been contemplating.  SHA is secure hash algorithm.  It's essentially a long number that indicates the properties and data of a file.  Well, if the SHA is the same for two files, then the file is the same.  So if you have a desire to back up data, you can create a SHA of every file on your system, and every file on the remote system.  Compare those two files together, and identify which files need transferred.  Do so, and you synchronize the data on both systems.

It's an idea.  Like I said, 10,000 hour is a lot of time.  A whole lot of time.  

side note: I realize this is April Fools Day.  I am not a practical joker.  

Wednesday, January 14, 2015

Some programming... more about planning

I think I’ve thought of the problem with the threading function.  There’s really no problem with the thread function.  The thread works great.  My expectations of what the thread should do were wrong, though.  I incorrectly assumed the thread would run multiple times.  It doesn’t.  It just runs once.  And that’s the problem with it.  So it’s not the thread’s fault I told it wrong.  It is simply a matter of me assuming the wrong thing about how it would behave.

Essentially, I have to remember that the thread is nothing more than a function.  The function runs, and then the function quits.  Bu nothing ever calls the function again, so the numbers never change after the first press of the button.   Or at least I think that’s the explanation.

On a second note, my reading has gone past 20% complete.  I should be done with Security+ this week.  As a general rule, I’d say the book has good info but it’s so incredibly vague in most cases.  This is not an action oriented book.  This book is there to give you a gigantic overview.  From there, its’ up to the user to pursue whatever interests them.  Which takes the focus out of the reading.  I’m guessing a server book should go next.  At the moment, I’m not progressing down the security path though.  I’m heading towards a programming path.  Once the programming path is done, then it’s back off to other things. 

At the moment, I’ve read about 1000 pages of the 5000 I need to complete my current goal.  So that leaves me with another 4000 or so to read.  Do I really want to schedule the next 10,000 pages when I don’t know where I intend to go from here?  I could easily pick a number of books.  A Cisco Voice book probably needs to be in there somewhere.


For now, the examination of where I want to go is behind 4000 pages of physics, calculus, and artificial intelligence books and the last 50 or so pages of Security+.  Towards the end, I’ll probably have a better understanding of where I want to go.  But now?   The schedule is set, I just have to follow it.

Tuesday, January 13, 2015

Threads: I still hate them

Hmm…

Looks like implementing threads is going to be about what I expected.  The code is simple enough.  It’s getting that thread to run multiple times on a schedule that’s going to be the complicated part.  I have no idea how to get it to do that.  The thread.sleep() should cause it to work, but it’s not doing what it’s supposed to do.  I suppose I’m used to dealing with threading causing me havoc.

Grr…   Slight modifications to the system and it still doesn’t work.  But eh… 

The real problem is threading is critical to half of the stuff I have running through my head.  So I have to figure out threading, or the rest of my ideas need to go on hold.  And I really don’t want to put them on hold. 

But…  grr. 


Did I mention I’ve never been good at threads?  In general, they seem to be easy.  But I’ve never been able to implement them properly.  Though quickly looking through the Java documentation, there is also a timer implementation that would probably implement the countdown portion of the clock just fine.  It still annoys me…  

Yeah, I still hate threads.   I wouldn't bother trying the code, as it doesn't work...   

    private class CountDown implements Runnable
    {
        CountDown()
        {
            
        }
        public void start()
        {
            t = new Thread(this, "counter");
            t.start();
            
        }
        public void run()
        {
           
            try
            {  
            
                int ones;
                int tens;
                String txt = seconds.getText();
                char characters[] = txt.toCharArray();
                             
                ones = characters[1] - '0';
                tens = characters[0] - '0';
            
                ones = ones - 1;
                    
                if(ones < 0 && tens > 0)
                {
                    tens = tens -1;
                   
                    ones = 9;
                }
                else if(ones < 0 && tens == 0)
                {
                    tens = 0;
                    ones = 0;
                }
                
            
                seconds.setText( Integer.toString(tens) + Integer.toString(ones));
            
                Thread.sleep(20);
            }
            catch(InterruptedException e)
            {
                
            }
            
        }
    } 

Monday, January 12, 2015

Java StopWatch: the down buttons

I'm still working on my Java Stop Watch.  I got the down buttons working over the course of about 20 minutes.  10 or so of was copy/pasting the code, and updating a few definitions.  The other 10 was troubleshooting what wasn't working properly.

There is a simple realization when you code: it will be wrong.  From there, you will need to fix it.  Life works much the the same way.  Anyways, here's how the buttons work.

First the mintues up button.

        ones = ones - 1;
                if(ones < 0 && tens > 0)
                {
                    ones = 9;
                    tens = tens - 1;
                }
                else if(ones < 0 && tens == 0)
                {
                    ones = 0;
                    tens = 0;
                }

Now, the explanation.  In this system, you have two separate scenarios.  One is that the number becomes negative.  We don't want that.  The other option is a reduction in place value.   I deal with them in the program in reverse order.  So we'll go with what the program covers.

The reduction in place value is a move is a dual comparison.  So...  If the ones' place is negative, and the tens place is greater than or equal to 1, then reduce the tens place by one and set the ones place to 9.

The other option is the value goes negative.   You can't measure negative time, or at least that I know of.  So, if the ones place is negative and the tens place is zero, set both places to zero.

The main point of both of these systems is the ones place reduction happens immediately.  That way, if the either comparison fails, then nothing is needed to be done and the function is complete (mostly) complete.  You still have to output the information, but that was covered earlier.

After writing the part that decrements the seconds, I changed the seconds incrementer to be consistent.  Previously, the seconds incrementer would go to from 59 to 00 and start back over.  But I didn't write the reduction to work that way, so I changed the system to stay at 59.   No rollover.  It's a personal program, so I'm not concerned about the system going in circles.


Looks like everything is working properly.  Next time, I need to write the threaded portion of the system.  Basically, during the "on tick" event, reduce the the display by 1 second until countdown is complete.

Maybe I'll get that working tonight.  Or some time.   Don't know.  We'll see.



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.

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.  

Tuesday, December 2, 2014

Changing passwords... and Eclipse


Want to figure out how much you know about a system? Change a password.  Sounds stupid, but automation is often setup under a single user account.  In a large company (I’m hoping) you find that only one password affects one process.  In a small company you will run into craziness.  But I would encourage you to change passwords, even ones where you don’t have a great deal of information on what happens when the password changes.

If anything, it becomes a good time to write documentation.  Let’s face it, you are supposed to have documentation on everything you do anyways.  Password changes are no different.  If you have built the infrastructure properly, then a password change should only effect one device or service.  That may seem like a lot of passwords.  It is.  But if you aren’t willing to put effort into security, you won’t have any.  

Moving on…

And Eclipsing we will go…  I took my final today, and I don’t have any site upgrades planned until January, so I think it’s time to get the mobile apps I have built in head tested and running.  That means breaking several things I would normally use at work.  But I suppose that will have to work.