Saturday, April 12, 2014

SMS to Machine

So today I wrote an Android app that lets you text from your computer (so long as it has a JRE).

Basically the server (SMS to Machine) runs on your phone in the background and you can connect to it from the desktop client (SMS Client) using the address provided by the server. All of the messages are encrypted with a password in the form of a SecureSMS object (essentially a pretty container with an array list of encrypted strings).

I wrote a miniature messaging protocol for the communication. All SecureSMS messages are wrapped with [BEGIN] and [END] tags to let the server/client know where content begins and were it ends. The connection first has to be accepted when the [CONNECT] command is sent. A disconnect can be achieved when the [DISCONNECT] command is sent. All other transmissions right now only contain encrypted content to be decrypted by either end of the connection.

Currently I'm still in a testing stage. It sends and receives fine, but I still have work to do. I've decided I'm going to send metadata in the form of JSON using the framework provided at json.org. And I plan on handling MMS by zipping images and sending a "SecureMMS" object through the output stream.

This sort of application already exists in the Playstore, but I honestly don't care. I'm doing this for fun (as with everything I write).

As of right now, it's a very small but powerful application with a primary focus on minimalism. I'm all about minimalism. And as few bugs as possible. ;P

Okay. Back to coding!

Thursday, April 10, 2014

The Battle for Optimization

So a little update on ZerothScript. The project has come along smoothly. But for the first time in years, I've come across an optimization issue. I set up my unit test in the form of scripts. One script for USL and one script for ZS. The test creates a variable for storing numerical values and loops one hundred thousand times decrementing the value by one each iteration. At first ZS was clocking in a little over half a minute while USL was finishing at nine seconds. This seriously boggled my mind. I didn't think something I wrote three years ago could possibly be any more efficient than what I can write now. I couldn't be more incorrect. I attacked this slowness issue in two ways: rewriting the interpreter, and removing the logger calls. Starting with the interpreter, I was passing the tokens down the chain of command and it was grossly inefficient. The interpreter is much more organized thanks to the analyzer function I wrote. The interpreter no longer needs to pass off the tokens down the chain of command. It goes directly to where it's supposed to go. This increased the speed by a lot but it wasn't good enough. The real speed increase came from removing the calls to the logger. Previously each call printed to stdout the stack trace. That was a terrible idea. I have no idea why I thought that would be a good idea. So this functionality has been destroyed. The error logging will still exist because it's necessary. I forgot the nature of a language of this sort required the code to be as bare bones as possible.

I was able to cut the time down to fourteen seconds. Those are incredible results to me. It's only five seconds slower than USL now. I'm about to merge the shell into the interpreter for efficiency purposes. Right now the only function of the shell is to contain variables and methods. It doesn't do anything else. So merging seems completely appropriate. I'll only merge the appropriate functions and variables. I can abide by the Law of Demeter in this case since calls to the shell just to get their variables (and their values) are heavily used throughout the interpreter. It was a good idea at first, and maybe it still is, but as of right now, optimization is what I need. I need this language to be faster and more powerful than USL. I truly believe that I can achieve the same speed if not better. It will take time, but I will get there. And if I optimize sooner than later, I won't have to work through a finished project to optimize everything.

I'm learning more and more as a software developer each day. Professionally, and on my own time. I'm seriously blessed to have this skill. I wish I knew more people who were as passionate about code as I am. One day, when (and if) I leave Oklahoma, maybe that will happen.

Okay, so what's new in ZS since I left off?

I've implemented variables (of type integer, double, and string) and for loops. I actually got nested for loops down to one nest! I had to deprecate nested control structures in USL. It doesn't seem like a lot of functionality right now (at least to me), but later on down the line (next month or so), I will have a completed language to expand upon. Right now I'm going to continue working on optimizations and start implementing if-statements. Then I will implement methods.

So this post is about an issue I had encountered, and how I handled it. I had to drop unnecessary features and rewrite some things, but in the end it was worth it.

Until next time! I'll probably check in the changes right now just for the heck of it.

Here it is: ZerothScript

Saturday, March 29, 2014

ZerothScript

I've been writing a new scripting language for the past week and I call it "ZerothScript" or "ZS".

ZerothScript ("ZS") is a hybrid typed, object-oriented scripting language. By hybrid typed, I mean, it will allow the retyping of a variable after initialization. The type checking of USL is absent in ZS. Variable types will be declared statically; however, the types can be dropped and replaced with other types. When the type changes, the value changes accordingly.

ZS will feature a programmable interactive shell, just like USL, except the concept of the shell has been abstracted and divided into three main components: the engine, the interpreter, and the parser. The engine can be best understood as just a means to receive input from the user (or via script). The parser is the first to touch the input, and depending on whether it's something the parser handles (creating a new shell, exiting the shell), it will pass the appropriate values back to the engine. If the engine gets a request for a new shell, it will add a shell and attach that shell to the interpreter. The shell is a stateful creature and an interesting data structure (in my opinion) because it is basically a giant container of information (starting off small of course). If the engine gets an unhandled response, it passes it off to the interpreter for interpretation. The interpreter is attached to the current shell in the engine, so anything that happens in there will be reflected in that particular shell.

This is the core of ZS. The rest will come in time as I continue its development.

ZS already has a skeleton for a cool error handling system and a cool debug mode logging utility. When I have some cool ideas, I'll jot them down in code. Here's an example of what I expect the finished product to look like:

# begin example script

class Object
    private
        _id as String
    public
        def new(id as String)
            self._id = id
        end
        def getID() as String
            return self._id
        end
        static def sayHello()
            say "Hello, World!"
        end
end

Object.sayHello()

o = Object.new("object")
say "I am an object of type #{Object.class} and I have an ID of #{o.getID()}"

# end of script


Similar to USL, eh?

You can view my progress at GitHub.

Monday, February 3, 2014

Dropper - A Free Local Network File Sharing Service

FIRSTLY... Since I started programming at BMSi, I've learned a lot about "good" programming. For all of this time I've believed I was fairly efficient, but the seniors I work with are amazing and they have shared a lot of cool techniques for helping me be more productive in Visual Studio (and with writing efficient code). For starters, I learned to use the With keyword effectively. And I learned how to write single line If statements. I learned that I should never instantiate an empty object to return (in a function that returns an object) unless I absolutely have to, and to just return a null value if necessary. I've also learned how to use the #Region directive. All of these things may seem super small, but they are definitely useful tools to add to my arsenal.

Anyway, on to Dropper! Dropper is a free local network file sharing service that doesn't require you to pay for space. Obviously, space can become an issue if the other client hard drives are small and the payload is too large. For this I have planned to set capacity limitations into the very first release. I also plan on adding a blocking feature as well as a file filtering feature (for which the implementation has already begun). I started this project yesterday but I will work on it at least a couple of hours after each work day and multiple hours on the weekend.

So how is it implemented? Since I'm now a VB .NET developer, I decided to start writing all of my software exclusively in VB .NET. The front-end is a very simple form containing a menu strip and some menu items (start/stop/exit, dropper path/file filtering), and the back-end is SQLite. At BMSi, I learned an efficient way to store error messages is in a database! So in the SQLite db, I have three tables: tblFiles, tblErrors, and tblPCs. I'm pretty sure that the table structure is at least halfway decent. I'll have my new senior dev friend take a look at it to let me know if I could do it better. Which brings me to another point: you HAVE to keep an open mind in programming. Basically, there are other programmers who are much more knowledgeable and who can show you better ways to do things. OKAY. Back to the table structure...

tblErrors: strIPAddress, strStackTrace, strMessage
tblFiles: strIPAddress, strUsername, strPath, dteDate
tblPCs: strIPAddress, strUsername, strComputerName

I tried to make the columns as descriptive as possible. I know I will probably end up adding more tables in the future. One I just thought of was a separate table for server files which would let me use tblFiles for just local files (as a sort of redundancy for extra security). And perhaps I could add a tblUser to store individual information about the person using the software (username, password, configurations).

I'll write more about this in the future. If you want to see the code so far, it's at Github!

Monday, January 20, 2014

My First Programming Job

I can now call myself a professional. This is seriously my dream come true.

I won't let them down. I am going to work as hard as possible. I bought Murach's book, Visual Basic 2012, last week and I'm already at page 630.

My life is finally falling into place.

And I could never be thankful enough. :]

Wednesday, January 8, 2014

SysMon update

I've been programming exclusively in VB .NET for the past few days now, and I'm pretty much happy with this language overall. I am still able to do the same things I used to thanks to .NET, and it's starting to grow on me.

Today I decided to work on SysMon again. I added a TabControl (.NET version of javax.swing.JTabbedPane), and a ContextMenu (.NET version of javax.swing.JPopupMenu) to control the components within the tabs. I added a Services tab which lists all Windows services, and when you right-click the list, it selects the index and shows the context menu (allowing you to toggle a service on or off). In that toggle, I learned how to use the VB version of the ternary operator. It's an If-statement used as an initializer! Very insane! I also changed the color scheme back to a more orthodox Windows style.

Screenshot time!


It's up at github!

Sunday, January 5, 2014

Turning to VB .NET

I might have a new job pretty soon! Finally, I will be saved from the world of retail!

The new job is a VB .NET developer position and as you might know already, I write most of my software in C#, Java, or C++. But I'm definitely not new to the VB world.

But I did need a refresher, so I decided to write a couple of applications today. The main one I developed is a system monitor. It's pretty standard. There's a thread running in the background that calls a thread-safe subroutine which updates the list of running processes. I used a SortedDictionary to sort the processes by PID, and the list is checkable, so you can check multiple processes and kill them with the "Kill" button. I also give the option to open the directory of the selected (not checked) process in explorer. But I'm not sure about how to select the file when explorer is opened at that location. On the left-hand side of the form is a list of changes occurring in the file system. Using FileSystemWatcher, I can see changes occurring all throughout the file system, and save the results to a log file. The log file begins with the current date and time, machine name, and current user name, followed by the list of changes found and the list of running processes at the time. And finally, in the menu, you can go to Tools>Run and choose one of the menu items (Command Prompt, Task Manager, Registry Editor, Notepad).

I already knew VB, but writing in it again felt amazing. Like the feeling you get when writing Python after you haven't used it in awhile, without wishing that all languages were like it (nerd humor that probably only I will understand). Anyway. Check out my source code, it's well documented in case you don't know VB. I also use a little Boolean trick (line 136) which I've used in C-style languages forever. It works in VB as well and you might find it useful if you don't use it already.

Here is a screenshot!


VB isn't so bad. The source code is at my github.