A cool article about Guerrilla Games and their office culture

A cool article about Guerrilla Games and their office culture

This article popped up on Twitter today, and I loved it.  First off, it gives the name of the Fallout: New Vegas writer I couldnt remember on the podcast - John Gonzalez, who lead that writers team, and the one on Shadow of Mordor (meh!) - second, I had no idea Guerrilla had such an open, creatively-minded culture.  Third, I love this paragraph about how they ended up producing (what I determine to be) the most successfully-feminist triple-A video game Ive ever played.  And the answer is exactly what youd hope:

"Aloy was always a woman right from the initial concept. While no one at Guerrilla expresses any kind of agenda when it comes to gender equality, as technical lead Michiel van der Leeuw notes, there was an awareness that female leads in games are often sexualized � a precedent the team had no intention of following. "She had to be agile and athletic. Shes an outcast but shes also brought up lovingly," he says. "There were so many elements we had to balance to make her the person she is. I like that people have picked up on her teeth being a bit crooked, her face being asymmetrical � I think people pick up on her imperfections because shes a real person.""

The article gives a really excellent impression of Guerrilla, perhaps most notably from Horizon writer - and new Guerrilla hire - Gonzalez, who moved from the States to Amsterdam to join the team, and now refuses to leave.

"Ive seen a lot of things and experienced a lot of things in the industry that would lead you to become cynical and disillusioned. I dont find that to be the case here. I feel like the level of ambition here is really high, but I dont feel like the ambition is high for external reasons, like wanting to be masters of the universe. Its high because people really care about the quality of the product. I just feel like I dont want to step away from that, you know? This is a place where I can improve myself, can bring myself to the work. I want to stay as close to that as I can."

A nice example of this is the ants on the trees.  You may have seen a GIF or video of the leafcutter ants youll find on trees, here and there - it was kind of a big deal when the game first launched.

little details like this impress me, ants carrying leaves on a tree [Horizon Zero Dawn]

Yknow why those are in the game?

"Its a level of attention to detail most wont notice, but one Guerrilla appears to do without consideration � even to the point where animators took time out of their day to render ants climbing up tree trunks, all of their own volition. ... "They felt like the environment needed something to make it come alive.""

So yeah, check the article.  Sgood stuff.

Read More

82 percent of IT pros think Windows 10 would make their company more secure

82 percent of IT pros think Windows 10 would make their company more secure

 

Security is an ongoing struggle for businesses and many data breaches can be traced back to the use of out of date software.
 
A new survey from systems management company Adaptiva asked more than 150 IT pros their feelings about their enterprises security, and found that the majority were concerned about potential vulnerabilities.
 
Among the key findings are that 82 percent of IT pros think moving to Windows 10 would make their company more secure. 70 percent of respondents are concerned about potential security vulnerabilities in their Microsoft SCCM environment and almost two-thirds (65 percent) of respondents plan to conduct an SCCM security audit within the year.
 
More about securing Windows 10 and SCCM environments can be found on the Adaptiva blog and theres a summary of the reports findings in infographic form below.
 

 

Image Credit: Andresr/Shutterstock
 
~ Ian Barker

Read More

A few things on Pythons Error Handling syntax and their usages

A few things on Pythons Error Handling syntax and their usages

As a noob in programming, I encountered code error very often. In fact, I am so used to it that I truly expect some error in every snippet of my code. When I dont encounter on, I feel genuinely insecure about it...

However, with the more experience I have now, I meet fewer errors in my scripts, and when I started building web application that requires user input, I need to worry more about mistake made by the user instead of myself.

That was the moment that I realize the power of Pythons error handling - yep, back when I was just learning Python, these stuff meant nothing to me, well, more or less, they are just meaningless.

The biggest problem with programs that take user input is, in most programming languages, when an error occur, the script will stop executing.

This makes a lot of sense in logic, but it is most certainly a very bad experience to the users.

Error handling will help us prevent such embarrassment - to us, as well as the users.

While take input from user, be it using raw_input or a form submitted over HTTP POST, we should not encountered much problem. It means that taking input is quite safe actually.

What is NOT safe is when we try to do something with the user input, which, is always the case - after all, if you are not doing anything about the input data, what is the point of collecting in the first place, right?

This is where things become dangerous - lets say you have a field that accept user to enter their birthday, without checking and converting the data in the front end, there are just countless ways an user may enter its birthday.

Consider these few possible date format: "28th September, 2014" , "28-09-2014", "28/09/2014", "28-9-2014".

While these date formats all make sense, but it would be really hard for us to handle such input, converting them into a format that our database use.

Alright, enough with the back story and logic behind using Error Handling, lets talk about the syntax and how we can actually use them.

There are mainly 4 keywords used in Python to handle errors.

They are "try", "except", "else" and "finally"

Just like any other Python syntax, their meaning and usage are actually quite straightforward.

First, we would need a try block in our code, say we are now going to handle the input data from the birthday field, and we want to try converting it into integer for processing.

However, we do not know if the user would be using a format with only number, therefore, we are not sure if the int( ) conversion function will work.

So, we write something like this:

try:
     data = int(birthday_input_data)

Just like we would normally operate on a safe string.

But yes, we are expecting error, because the user may use a format that contains ASCII characters.

If we try to use the int() function on a string with ASCII letters, Python would raise an error like this:
 

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: invalid literal for int() with base 10: foobar

As we can see in the last line of the error message, the resulting error is called "ValueError" in python, which is the Error Type we aimed to solve with our next block, so we are going to write it like this:

except ValueError:
      #do something with a data input with ASCII string


Alternatively, if we are not sure what else Error could be cause ahead of time, we can prepare a fallback general-purpose exception case like this:

except:  #with no ValueError class
     #report to the user that a fatal error is caused and the script cannot proceed with the input
     #nicely ask them to try again.


Of course, just like an IF block, we can add multiple layers in the try block to try to handle different possible cases before handing it to the fallback exception.

But what we the code worked the first time? With no error?

In this case, we can add an ELSE block after the TRY block. Like so:

else: #no error
     data.insert_to_database()


Lastly, we do also set a default action to an error handling block at the end to safely close files or re-collect resources. This is done by using the "FINALLY" block at the end, which will always get executed whether there are errors or not.

In our example, we might want to do something like this:

finally:
    db_connection.end()
    #or
    document.close()
 
Thats it.

Again, I wrote these stuff not trying to be a guru, but simply because I am that kind of person who always want to know the rationale behind something before I can fully understand a concept.

The benefit of writing error handling code took sometime to dig into my stubborn head, I hope this article could help someone like me, struggling to understand the purpose of some code.

Read More

A general approach to command line switches and their default values in Perl

A general approach to command line switches and their default values in Perl

In the UNIX world youll rarely find a program which doesnt support a few or many arguments (or command line parameters) which influence the execution of the program.

When Perl programs require arguments (one of the simplest cases: an input filename) one could investigate the ARGV hash (an approach which works well in easy cases) or one could turn to one of the Perl modules, in particular if the arguments are command line switches.

In this article I will discuss a few types of command line switches and the possible logic behind.

What is a command line switch?

Just to recap: a command line switch is traditionally denoted as a hyphen followed by a letter optionally followed by a value e.g.  -d or  -d 25 . Note the space between the switch and its value. Some programs require this space whereas other require the value to be attached to the switch like -d25 and still others allow both. Some programs allow switches to be concatenated like  -ltr instead of  -l -t -r . Others allow switches to be more than one letter. Some programs allow a switch to appear multiple times like -v in awk.
Further complexities exist: one switch might override others. Some switches exclude each other mutually.
All these cases would need to be handled properly.

On top of that (I think it was) the GNU world introduced double hyphen switches with (usually) string switches e.g.  --verbose .

In the remainder of this article I will only use the simple case of single letter switches with or without argument. I will be using Getopt::Std, one of the core Perl modules and its function getopts. Its basic usage is  getopts(ab:,%opts); for two switches  -a and  -b foo.

Various types of command line switches with or without default values

The typical distinction between command line switches is whether they are boolean (switched on or off) or carry an additional argument. Then there is the question: if a command line switch is absent should there be a default value used in the program?

The following table explains the differences and shows a few examples.

switch	Example	Default	Notes
-a	...	false	A boolean switch by its very nature has a default value true or false which should be the opposite of what the switch intends to trigger.
-d $HOME/tmp	output directory	/tmp	Certain things in the program require a default value e.g. the program needs to know where to store its output files. Its left to the programmer to decide which of the default values can be overruled by command line switches.
-u joe,sandy	user list	current user	Some command line switches can take more complex arguments, in this case a comma separated list of users. Its absence should be covered by a reasonable default value e.g. the current user.
-p 1507	process id	all processes	Some switches do specify a setting which acts as a filter or a kind of a restriction but its absence does not imply a default value but is somewhat vague. In the user list example before another default behaviour could have been all users instead of current user.

Rather than defining a list of variables to set the defaults like

 $OUTDIR = "/tmp"; $USERS = $ENV{USER}; ... 

and later somehow associate these variables with the switches a (in my view) cleaner approach is to

define the defaults in a hash (the keys are the switches)

create a new hash (again with switches for keys) and set them to either the defaults or values supplied by the command line
The following Perl program handles the cases above.

boolean switches and unspecified defaults are set to undef, all others are set to their reasonable default values.

the  ... ? ... : ... operator is used to set the actual variables
(Getopt::Std sets boolean switches to 1 which represents true, the opposite (and default) could be anything that evaluates to false in an if(...) clause, I chose undef rather than 0).

 #!/usr/bin/perl use strict; use Getopt::Std; # to process command line arguments # Define the defaults in a hash my %defaults; $defaults{"a"} = undef; $defaults{"d"} = "/tmp"; $defaults{"u"} = $ENV{USER}; $defaults{"p"} = undef; # Retrieve the command line switches into a hash # making sure which ones are boolean and which require an argument with : my %opts; getopts(ad:u:p:,%opts); # Put either the default values or the command line switch arguments into a hash my %vars; foreach my $key (keys %defaults) { $vars{$key} = exists $opts{$key} ? $opts{$key} : $defaults{$key} ; } # Test output: see what is contained in vars foreach my $key (keys %vars) { print $key," ",$vars{$key}," "; } print " "; # Check decision tree for boolean and unspecified switches print "a is set " if( $vars{"a"} ); print "p: all processes " unless( $vars{"p"} ); 

If run without any command line switches:

 u andreas p a d /tmp p: all processes 

With -a and -u

 ... -a -u joe,sandy u joe,sandy p a 1 d /tmp a is set p: all processes 

With -p and -d

 ... -d $HOME/tmp -p 1507 u andreas p 1507 a d /export/home/andreas/tmp 

With this general approach one hash vars contains all the information and its contents can be used directly later in the program (like -d output directory) or used in a decision process defined vs. undefined.

Of course there are more issues like the ones mentioned above (e.g. conflicting switches) or validity of values (e.g. does the output directory exist and is writable) but they need to be resolved somewhere else in the code.

Read More