One of the biggest updates in terms of what it brings is the move from MySQLi to PDO - PHP's data objects for databases. Not only does PDO make it easier for me to add future database systems, it makes it easier for me to write the code.
MySQLi's biggest problem is the way in which prepared statements are formed:
$stmt -> bind_param("ss", $username, $password);
PDO solves this issue by making it possible for me generate any query and provide any number of parameters, thus allowing me to call the execute on the query at just one point. If you look through the new version BalfBlog you will understand why this is crucial.
Nothing will change on the front end, although the performance is much better with PDO because of the way it is written.
I may have only posted the other day, but this update is a big update so it needs to be out there.
Version 2.3 will be a big overhaul of the internals of BalfBlog, similar to what happened to ZPE. This is a major code refactor and therefore it will take me some time to finish it. I am now improving the comments inside BalfBlog to make it easier to work on, changing the way variables are named, defining more constants and generally refactoring the code.
If you wish to contribute, get in touch.
Although it's easy to find out about BalfBlog through the changelog, I thought I'd update you here.
The latest revision of BalfBlog is a bit of a step up in terms of security and performance. The main new features related to user accounts. Every BalfBlog installation from version 2.3 (Goldfinger) will now feature a special user account called helpdesk. It is disabled by default, so an administrator has to enable it in settings. Once it is enabled, helpdesk is used to allow me to remotely login to your blog and help you with issues. I suggest leaving it off unless you need help.
As well as this, at the end of February I added the switch user functionality, which allows administrators to use the user account of any user without the need for a password. This also is designed for debugging and will allow administrators to debug the system themselves. I also changed the dashboard menu to a new accordian style which keeps items better organised. You will see other asthetic changes across the website, including the new login page. On the development side, you can now switch quite easily to CKEditor instead of TinyMCE for a more lightweight editor (more editors will come soon).
I have recently begun work on the new Message Centre. I will primarily be using this on my blog to record issues. This new system allows you to setup an easy to use message system whereby users can get in touch. You will be able to set expiry dates on messages so they will only remain in the system for a few days.
Also coming in Goldfinger is the new logging system. This will allow you to see what people are doing in the dashboard. I will also be looking into building a comment system that I will integrate into BalfBlog. Version 2.3 will also possibly be changing from MySQLi to PDO, but we shall see. A new file manager is also planned and I'm looking to improve performance too.
I'm still working on improving the file upload system for images, which is no longer working.
As with all version of BalfBlog 2.x, HTML5 and CSS2+ is required to be able to actually use it, so please just stick to Firefox, Edge, Chrome or Safari 6+.
As part of the major restructuring of the internals of my ZPE project, I rewrote the whole parser. Before I explain what's changed with it, let me explain how ZPE works (and still does).
The previous image shows precisely how everything interacts. The second step is the most crucial, at least I see it that way. I say this because this is how my latest project functions. The project was known as Project Diamond originally, and I have no idea why I chose to name it that. This project looked at a new way of making the ZPE parser flexible and as a result ended up with me rewriting the whole ZPE parser (it's not that big though, only about 100 odd lines). Because of this rewrite it can be used to parse any language with minimal effort. Simply including the parser and requesting it does an action (such as eat a word) or return something (such as the current symbol or the current word) is all that is needed to write a programming language using it.
As a result of this, I wrote JBSON, which is my JSON parser. It works using my ZenithParser which is now fully open to use. It's very easy to use and I will share the source code of JBSON. Whilst JBSON is actually part of the ZPE package, it can be used completely separately and the whole ZPE package is not that heavy. However, as I am restructuring ZPE's internals I may make it a public library that's not a part of ZPE. The main motivation behind doing this was the Google's JSON was too big for ZPE, adding it doubled the size of the distributable JAR file.
Back in the days of version 1.3 it was always my intention to make it possible to add custom compiler syntax to ZPE. I did this originally in a very simple way that made it easy for me to develop but harder for others to develop. Today, version 1.5.2 brings this feature back. It improves it considerably and makes it fully possible to write your own syntax. I've even decided to make it possible to overwrite the built in keywords including things like if and while.
How does this work?
It's not the easiest of things to explain but I will try. Firstly, when ZPE is launched it will search through all of it's plugin directories. A new directory called 'keywords' has been added to version 1.5.2. This directory contains all of the user's custom keyword plugins. The manager then adds these to the compiler based on the name value given to the keyword plugin.
The next stage is for the compiler to compile the word. The plugin handles the compilation job and can access the owning ZPE's public functions (including the new ExternalMethods object) before returning an AST.
Within the interpreter the plugin's traverse method is called. It is then the plugins job to traverse when the plugin is given an AST back (the same AST given previously) and to run it as code. It's pretty easy to do and it's designed to be easier than doing it the way the internal compiler does it.
Below is a plugin called 'jack'. It simply takes the next word and stores it as a value.
import jamiebalfour.zpe.core.AST;
import jamiebalfour.zpe.core.ZenithEngine;
public class ZenithCustomModule implements jamiebalfour.zpe.core.ZenithCustomModule {
@Override
public String GetName() {
return "jack";
}
@Override
public AST CompileToAST(ZenithEngine z) {
AST a = new AST();
z.ExternalMethods.EatSymbol();
a.value = z.ExternalMethods.GetCurrentCompilerWord();
return a;
}
@Override
public void Traverse(ZenithEngine z, AST node) {
System.out.println(node.value);
}
}
Below is a sample of the ZenLang code that runs this:
function main() jack x $a = 0 end function
Thanks to some of the comments I received today about my website, which were largely positive, I will be changing my website quite considerably.
The comment that has stuck with me, and it's reinforced by the fact I've thought about it myself is that my website has become too big. I've developed a plan of action to tackle this problem in as few distruptive steps as possible (since now my tutorials have been gaining more popularity and my website is being used by many, I don't want to disrupt that).
My plan is this:
- Revert back to a single blog again, my Projects Blog will move back into my main blog.
- I will merge Software into my Projects section.
- I will create a completely new website (I've been thinking about this since early December) for my professional works
Whenever I am asked why I bothered building a personal website or why someone needs a personal website my reply is often something along the lines of 'it's fun' or 'it's my hobby'. But I very rarely touch on the benefits of my personal website.
There are a huge number of benefits to my own personal website. I get around 500 visitors a month on my website. I use it to showcase my work to potential employers, to get myself on the internet in a public way that people can connect with me through but there are also other things. I enjoy learning and teaching, so my website is also a source of information where I put tutorials to help others learn stuff that I know.
But really what's the benefit? My first answer is that it's professional. The brand that my website pushes forward gives me a uniqueness that appears on all of my work now. The orange and blue theme of my website is also apparent on my CV, any letterheads I send and on certain emails. This looks highly professional and people like to see this. I also believe that having your own brand puts you above others who do not.
The second reason that having a personal website is that the website is, well, personal - it's all about you. LinkedIn is great for connecting but it's full of other people too. Go to jamiebalfour.scot and who do you think you are reading about? That's right, some guy called Jamie Balfour. There's nothing about John Szymanski or Murray Smith on there (well there might be). This keeps the reader focused on you. You can write soley about how good you are and all of your achievements and yeah, be a narcissist, blow your own trumpet!
The third reason I would say having a personal website is a must is because it gives people an easy way to read about you. A personal website allows people to read about you from all corners of the globe. Social media is great, but it's also ladden with other things, like other people, a like LinkedIn.
I will admit my website is more of a personal project that evolved into something more. For anyone in computer science it's pretty nice to show that you can build a website from scratch, so I did exactly that (it shows a lot of perseverance too).
ZPE CAST or ZPE Client And Server Technology is the way in which Remote ZPE (rZPE) works. It is currently based on a point to point communication protocol through a single port. A server initiates and a client sends a request for a connection. It is currently based on a multithreaded server that opens a ZPE command line to the client. This allows remote testing and more importantly remote access to a system. It currently does not encrypt the connection, but I am working on bringing this in the near future.
The ZPE commands that do this will soon be removed, in favour of the -n ZAC that was added in version 1.5.1. I will be redesigning the message consoles too so that when a server is connected to a client, the client opens a server and sends a request to the server it has connected to open a client and connect back, reducing the number of jobs needed by the users of each client and server.
All of this is planned for the next version of ZPE, version 1.5.2.
Also, the CLI version number put at the top of the zpe command in every version to date has been incorrect and only outputted the version number of the ZPE application. It has now been updated so that it displays the correct information, showing what version ZLC (Zenith Language Compiler) is in. As of 1.5.2 this is version 1.6. Also, the ZenEXecutable specification has changed, thus all compiled programs need to be recompiled.
ZPE 1.5.0 brought a ton of new features that make it better than it ever was. But version 1.5.1 has brought about even more. Now version 1.5.1 which recently was released to beta users has been improved further. It's main focus has been on improving the back-end compiler, and it seriously has. The compiler now follows a different path to the interpreter, something planned for a long time. This update changed ZenEx and how it works compared with before and will mean that you will need to recompile any applications written in ZenLang.
On top of this it has received some Java-based TLC. Users who develop Java applications will have a much easier time accessing what they need, when they need it. Everything is now packaged up in to a bunch of very neat little packages and classes, rather than all residing within the ZPE package. For instance, you can now find GUI based stuff in:
jamiebalfour.zpe.GUI
And the core is now found in:
jamiebalfour.zpe.Core
Easier by a long shot.
Also, the public methods class called PublicMethods is now found at:
jamiebalfour.zpe.Core.PublicMethods
This was added in version 1.5.1 and it adds many new methods that are there for developers to take advantage of. One such example now opens all internal functions to Java developers, no longer limiting them in to using ZenLang to access these (prior to this the plan was to use the public Execute function to get a result).
BalfBlog is making a big change today that will change a lot of installations. Luckily there is a new plugin included by default with all installations that fixes this.
The fix I speak of is moving from using MD5 in any hashing algorithms at all. I was interested in finding out whether or not MD5 was a preferred choice to SHA1 for a short URL and came across a page in which the write manages to produce two images which are distinctly different yet the manage to produce the same MD5 value causing a collision. Not good.
As a result I have decided to change from MD5 being used to generate hashed URLs to SHA which has a much lower chance of a collision than MD5 does. For more information on creating collisions (and it's a very interesting article) look to here:
http://natmchugh.blogspot.co.uk/2015/02/create-your-own-md5-collisions.html
