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, 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.

Tuesday, November 26, 2013

JediChat update

I got the server GUI working right (for the most part). I'm going to post an image of my progress (yes there is one error in the chat dialog, BUT AT LEAST IT WORKS).

So here is an image!

I have two clients and one server. And a launcher in the upper left-hand corner (but you can't see it). The default port is 31337, but you can change that. Just click the "start listening" button and the server will wait to accept new client connections.

See the error? [NEW_USER] is one of the software-level protocol broadcast messages I spoke about in the previous post. It's broken here, but the error gives an opportunity to explain what it does. For now, I only have [NEW_USER] and [USER_LEFT] (tells clients to update online user lists), but I'd like to work in some others in the near future. When the client reads the special broadcast messages, it doesn't treat them like regular messages, it tells the client to do something. It reminds me of my scripting language, and how it works. Very similar. Very awesome. I really like where this is going.

ANYWAY. I've got /connect user@server:port and /disconnect working and I have a lot of other cool slash commands like /nick and /who, but I also have a new command in mind: /new user, which will open a privatized chat tab!

OKAY. Well. I'm off to bed. It's 4:00 AM here in OKC. 1337dr34mz c0d3junk33z