Amp's blog

Amp Blasts: eSports!

Disclaimer: The following is written for humor and falls under the SX usage policy.

Ok, I retired 'Amp Blasts' back in May as at that point I couldn't really think of much of blast. Since then though, quite a bit of shit has went down. In addition, personal life events happened which inspired a special level of bile and fury that I haven't had in a long time. The end result is that I have decided to revive the blasts and go after eSports, one of the biggest loads of bullshit I have seen and I'd like to start with a comparison.

First off let's take a look at the majority of people who are developers at work. We see them working on design, or programming outright without showing very much emotion aside from when they communicate inter-personally. (Yes, I'm going to destroy the anti-social stereotype cause most developer jobs are on a team, thus necessitating social communication.) They are working productively on projects that will help the bottom line of their employer and at the same time hopefully furthering their own skill-set. Some of these jobs may be thankless for a variety of real world factors that can cause somebody to be unhappy with such a job, but that is normal. At the very least, they have a good living and are trying to be a productive member of society.

Now, I'm going to take a look at many eSports "professionals." They spend most of their time playing a videogame for hours on end, communicating only with people on their team and often in crass, unprofessional ways. Their social skills with most outsiders often reaches jack and shit. They are spending their time not being legitimately productive on anything, but just playing a game in the hope of somehow making money from playing a games that probably stopped being enjoyable due to the overkill of playing it. To me, this is fucking pitiful and the fact that people honestly think that eSports will pay the bills in the long run shows me they have no common sense whatsoever.

Threading in C++

In my threading tutorial at https://www.soldierx.com/Threading I covered how threading was handled by different languages. In particular, I stated that I was not particularly a fan of the threading implementation used by Java due to the fact that it forced the user to either use polymorphism (courtesy of the runnable interface) or to made a subclass of the Thread class. The biggest reason for this dislike is that this is more work than is necessary. Well, in some respects Qt works similarly on threading which bothers me a bit.

There are two ways to handle threading in Qt, and honestly it feels like a brilliant solution to a problem that shouldn't exist in the first place. The first one is similar to Java as it requires the QThread class to be inherited. The second one is to use a "worker" class with a series of signals and slots to handle the threading. Based on my experiences with other languages, both feel like a considerable amount of work that results in code that doesn't look as elegant as it could be so I feel the C++11 threading included within the STL to be the better solution at this point in time.

Overall, this shows that there are instances where using the basic STL can often yield a better solution than other libraries. I know that Qt has its own list class, but the STL rendition of lists is one that to me, did not necessitate a reinventing of the wheel. At the same time, there are some specialty list classes used in Qt such as QStringList, that have some capabilities that are more beneficial for the GUIs. With all of this taken into consideration, it is always important to investigate the best combination of clean code and efficiency.

Handling Multiple Forms in Qt Creator

Before I go on with this post, allow me to say Happy Holidays to everybody around SX. Make sure to spend time with significant others if at all possible.

Now that I have that out of the way, I spoke about my initial impressions of Qt Creator as I have done some side practice with it along with working on the GUI and some aspects of the OFACE backend. (One of the major parts will most likely be worked on this Friday and if there is enough demand, I may do a timelapse video of my codework.) For those who may have read my basic programming concepts tutorials, I talked about basic memory allocation in C++ and how this is good to know for C++ and in many cases other languages regardless of if they use a garbage collector. Well, in Qt Creator I have been working with how to handle multiple forms. Now, in the case of something like C# within the .NET framework, this is a pretty cut and dry task. However, this is a different ballgame when it comes to Qt Creator.

Adding the form in question only requires a Qt Designer Form Class to be added to the project, but doing this doesn't just mean that it can be called and all is good. When this is done, the ui, header, and cpp files are created for the class and if the class is dynamically allocated without deleting the memory after the object is no longer in use, the end result will be a textbook entry level memory leak. At the same time, calling a new form up from a method that is used for a signal event does not allow for such deletion to happen immediately as it would immediately close the form. Fortunately, there is a good way to handle this.

Initial Qt Impressions

With OFACE development having begun on my end officially when I have time available, I figure I would share some of the good and bad about what I have seen with the Qt Libraries so far. Now, despite my knowledge and experience, I refuse to call myself and expert in many programming concepts and merely just a journeyman who is working to become as diverse as possible. In addition, these are impressions that I have based on the work that I have done up to this point with the library which has been less than a week. Overall though, my initial impressions have been positive.

The IDE that I have opted to use is Qt Creator straight out of the gate. This provides me a WYSIWYG setup for many of the GUI elements. I will state that for the form-based work Qt Widgets is recommended, but for more dynamic content (such as having animations) Qt Quick serves as a good solution. The bigger advantage of this IDE is that for C++ work it is far better than the horrific experiences I have had with getting Eclipse to even work. This is a good advantage to me.

Another advantage is that the Qt libraries are much more powerful than I have anticipated. Some of the tasks that I thought I would have to create manually with C++ (which while annoying, was something I was wanting to do for some aspects as for OFACE I want to avoid some of the libraries provided by Windows for C++ due to their antiquated nature.) I actually found preexisting libraries to simplify matters and speed up development. I will state that some of the libraries are not perfect and I don't like some of the example usages, but that is me nitpicking a bit. Overall though, the libraries do go a long way in helping make platform neutral products.

Back around for now

Hey, just dropping a line to mention that I just finished up my bachelor's degree in college. (Also received Summa Cum Laude and Departmental Honors.) Now that I have finished up this particular work I will have quite a bit more time to work on some projects that have been of interest to both myself and to SX as well. At the same time though, I will be looking into employment (I won't go into any further detail as I feel it isn't necessary to go into detail with many aspects of my life as to be quite honest, it's rather boring) so I won't be doing the whole 24/7 availability deal.

With this in mind, I have come up with a bit of a very rough basic idea for one of the main parts of how OFACE would run. In addition to this though, as I have decided to use C++ there is a matter of developing a GUI for it as well. The honest to god's reality is that should I develop this using modern Visual Studio releases, this forces me to use the .NET framework and I do not wish to have such a requirement on that project. I looked into GTK but many accounts have stated that it is not a fun experience to work with. After much consideration, I made the decision to look into Qt for the GUI and GCC 4.8.0 so that I can take advantage of the newer C++ capabilities as some of the boost libraries they have included are pretty good. I will start messing with Qt a bit shortly and looking at if it would be the best solution for this.

Brief Notes

I figure I would make a quick blog post for those who do read this and mention that I have not been able to get much forward momentum on OFACE (I have started writing code for one of the main modules for it, but have yet to look at GUI aspects as I wish to have a strong back-end first.) due in part to real life events. In particular, I am finishing my undergraduate studies which are taking up quite a bit of my time. After this is finished, OFACE will be a priority project that I will most likely be working on during Christmas.

OFACE: Consumer of Crew Members

Well, looks like I have been asked to take a stab at OFACE by RaT. I have read through the notes about it (Of note being https://www.soldierx.com/bbs/201101/OFACE-Testing?page=2#comment-12597 which makes some good points) and have decided to come to a few decisions.

1. OFACE may benefit the most from being redone from the ground up.
2. The main initial focus will be on a minimalist, effective, and expandable core back-end.
3. The initial focus will be on working with a small number of applications to create one template that allows for OFACE to be expanded in a modular manner by both myself and others within SX.
4. GUI is to be focused on after the back-end is in an acceptable state.

This is what I have seen of this so far and over the weekend I will be fleshing out more details of this with RaT.

Basic Programming Concepts recommendations

At some point today, I am going to try to wrap up the sample code for the Threading section of Basic Programming Concepts. (I prefer to confirm that the samples I do work as I have caught some issues with how some of the code did not display correctly with the java tag.) With that in mind, I figure I would ask what other basic programming concepts should be covered on here. For that matter, are there more non-basic concepts that should be covered on here that aren't? I want to hear from the community on what they want to see as I would like to add something new to this series every other week if there was enough content for it.

Who I was and who I am

I have thought about this quite a bit for the last three weeks now and here's the reality is that who I was and who I am are becoming two drastically different people. In the past, I was a bit of a shithead and I have to face up to it for better or worse. As such, I have worked to diligently make myself a better person. It is not an overnight process and everybody makes mistakes though.

The honest reality is that time changes a person and having a different perspective changes things. I am very proud to have received some great opportunities from SX over the years and I know that for better or worse it is the most enduring part of my life. Not just my life as Amp, but my outside life as David. I owe SX quite a bit as during some really bad times in my life, they have helped me and in some cases I really didn't deserve it. As such, I wish to express my gratitude to the community as it has helped me through the past couple of months.

Defcon 21

This is going to be a different write-up than what I saw with how Blake wrote up one of the Defcons. I wish to talk about the positive and negative about Defcon, but first I will explain why I finally went back. In the past decade, circumstances beyond my control had kept me from doing so. However, this year I decided to make this happen as at the time I made this decision, it may very well have been my last clear chance at going. In addition, due to what I consider a less than stellar experience with academia (I am about to graduate and feel that I should have learned far more than I did to be honest) I wanted to see a different perspective. Overall, I saw both the good and the bad.

The Good:
- The Villages were good for learning new skills.
- The Darknet Project, while flawed, was a great experiment to teach neophytes good skills.
- Some really good contests that give an effective test of skill.
- Some pretty good parties and one of the best music sets I have heard in the past decade. (Seriously, I wish more places would play sets like this.)

The Bad:
- The larger area for Defcon works against having small groups come together sometimes.
- Other crew members have stated that this year's speakers were less than stellar. (Due to my unforeseen success in the Hackers Against Humanity tournament, I was more preoccupied with that and Darknet than with the speakers.)
- Some aspects of the con felt a bit less lively than before in the eyes of some crew members and I do agree with some of these concerns.

Syndicate content