The Ultimate Oldschool PC Font Pack is a collection of Creative Commons Attribution-ShareAlike 4.0 International License fonts that cover quite a huge selection of the original hardware PC fonts. No wonder it's the ultimate!
They could be useful in terminals or IDEs, I'm sure, but I could also see this used in some sort of video game where the classic look-and-feel is desired.
Tuesday, July 4, 2017
Monday, February 20, 2017
Static Methods vs. Constructors
Recently I had a discussion with a colleague about static factory
methods vs. constructors. Specifically, this was about using static
factory methods or constructors to convert from one type of object into
another type. I argued that, if given the choice, constructors should rarely
be used for converting from one type to another, and in fact, having
many constructors is usually the least desirable of several different
strategies of obtaining an object instance. I will only discuss one of
those strategies here, which is the previously mentioned static factory method.
I won't start with why static factory methods are good and when they should be used. Instead I'll start with the list of negatives about static factory methods that my friend provided, and discuss them one-by-one:
Static factory methods do not fall into the constructor area of the JavaDoc therefore a user must read down the doc or code to find a method that constructs the class
No disagreements there. I vaguely remember encountering this multiple times when starting out with Java, like with Calendar. I couldn't see how to create a Calendar easily, because when I used new Calendar() it was abstract and I'd need to fill in methods to make it work. Then I found out that I should use Calendar.getInstance(). Pretty easy after that, and as a bonus I didn't even need to know if what it created was a GregorianCalendar or something even more spiffy.
So yes, it is "hidden", but this happens so much in Java (for valid reasons) that it'll only trip up novices. Or, the class is so HUGE that it is buried in the JavaDoc or in the IDE autocomplete list. In that case, the class has other problems.
[Update: I saw some code from a different colleague who, instead of using Calendar.getInstance(), created a new GregorianCalendar. So there may be more to this point than I initally gave credit. Also: if you're coding in Java and the project allows it, stop using Date and Calendar and switch to the new date and time methods provided in Java 8, or use the JSR-310 backport if you're still stuck in Java 7 for whatever legitimate, but still lame, reason.]
A constructor is allowed to set variables directly at construction time. During this time if an overridable (non-final) method is used it will generate a warning.
But we can set fields with other methods, provided the field isn't final. And even if the field is final we can still modify it, providing the field isn't one of the primitives (int, double, boolean, etc) and the field's class provides setters. In Java, the only thing that final provides you as a field modifier is that it prevents you from pointing that field to a different object in a different memory location. (Yes, this means that just because a class's fields are all marked private final doesn't mean the class is truly immutable. You must also look at the type of each field: those too much also be all primitives or immutable classes (and are immutable all the way down). Only then is it considered immutable.)
The issue with why it is unsafe to call a non-final setter method from a constructor is because if the child class overrides the setter, then the parent class's variable might not get set if the overridden setter doesn't call super.setX() too.
The straightforward answer may be "then don't use setters in the ctor, set the values directly", but that is pretty tedious if the setter had some complex logic in it: that complex logic would need to be repeated in the ctor too, and if you change one, you'd need to remember to change the other. Thankfully, the solution is straightforward enough without resorting to copypasted code: put the complex logic into a private setXInternal(...) and have the ctor and the setter call into that. Granted, we can only do this if we still want the class to be mutable. If the class, or that field specifically, is to be immutable, then there's no choice but to use a constructor... but this can still be worked around somewhat. I'll explain later.
None of the restrictions or benefits of constructors are available
I'm not entirely sure what my friend was getting at here. We can still have the static factory method call the constructor if we wanted and get all them tasty restrictions and benefits. The thing is, sometimes we don't need the restrictions that a constructor has. With a static factory method, we could even return null to indicate a failure state (which I wouldn't advise doing, but this option is still available to those that want it).If the class was abstract, we could even implement the missing part we need, which the caller might actually like if they don't care what exact implementation of the class they get, as long as it adheres to the interface. This has a name of "static factory method" and it is widely used in the OO space, and it is beautiful. Admittedly, it can get overused if every class does this; simple constructors for simple classes are good enough.
I'm breaking the next one apart because it is several items:
it is a less efficient[sic].
In the basic case, yes, it is less efficient because instead of one call to make an object, it now requires two. But it can be more efficient, which I'll explain later.
It is less efficient. It requires the memory for a static method but saves no time. A new class must still be constructed, and then extra steps are required to set each class variable. Assuming there are any optimizations for construction we get none of them.
Okay, so the classloader part of memory has one extra method to store, which isn't a big deal. It consumes the same amount of memory whether there is one object instance in memory, or 5000. In other words, the memory load per object is zero.
As for saving time, true, in the basic case it saves no time because it is calling a constructor, which the caller could do directly. But it can be faster than constructors. I promise I'll answer this shortly!
A new class must still be constructed, and then an extra steps are required to set each class variable. Assuming there is any optimization for construction we get none of it.
Again, in the basic case, a new class must still be constructed. But since this static method is part of the class code, we could directly set the values if we wanted, but might as well use a constructor at that point anyway.
As for optimization for construction: because we're using setters here, and because I'm not privy to how "optimizy" the HotSpot VM will make a frequently called operation, I will agree that we lose out on the optimization because I have no idea what it would do.
There is no way to enforce immutability
True dat! It's the constructor's bread and butter. But we'll get back to immutability in a little bit, because believe it or not, that is where static factory methods can have the most benefit.
The calling method will not have the new keyword visible: Thing a = fromSomeOtherThing(SomeOtherThing sot)
I think the claim here is that...
...is a more beneficial, visible cue to the reader that we have a new object, and...
...is not as good of a cue. This is an issue of preference. My
preference: if the class is simple, and there aren't any objects we'd
like to convert into this class, then use a constructor. If we're
converting from another class, I prefer that a static factory method is used for the
conversion, because we can read right there what we're
converting from, and what we get.
The counterpoints...
Constructors can't have different names for one class, which might look funny if they all must do different things in order to return the instance.
Sure, you won't have any problem with your constructors if you only need to pass in different complex objects. You won't have any problem with these constructors:
public MutantAnimal(Dog dog) {
// make a mutant animal from a dog input
}
public MutantAnimal(Cat cat) {
// make a mutant animal from a cat input
}
But what if you need to take in animals from different serialized data, like this:
// Won't compile (and bad for other reasons anyway)
public MutantAnimal(String xml) {...}
public MutantAnimal{String json) {...} // ERROR!
Can't do it. If we MUST do this only with constructors, and not static factory methods, we can pull this ugly trick:
// Ugly and not recommended, but doable
// Handles both xml and json! Yay?
public MutantAnimal(String text, boolean isXml) {
if (isXml) {...}
else {...}
}
Gross. What if we want to handle yaml too? We could use an enum instead:
// Still ugly, still not recommended, but doable
public MutantAnimal(String text, SerializedType type) {...}
Yep, still gross. Perhaps instead we could make it a single public SomeClass(String text),
and then have it cascade the attempts to convert it from xml, then json, then
yaml. So inefficient! Even uglier!
If we give up on the "everything is better as a constructor" idea and use static methods that know how to do the conversion for us, things become much more simple and straightforward:
// Better than the previous examples
public static MutantAnimal fromXml(String xml) {...}
public static MutantAnimal fromYaml(String yaml) {...}
public static MutantAnimal fromJson(String json) {...}
It is so much easier to read, and more efficient. Another benefit of these static methods is that we don't have to keep it
with the class. We could move it out to a utility class somewhere if we
wanted.
Notes: Before anyone goes off and creates their own fromXml/Yaml/Json methods, you should know that I created these as a simple example of how constructors can fail you if you want multiple constructors but one or more have the same parameter list. I wouldn't recommend anybody create these from... methods. Instead, go find a nice library like Jackson and use the features it comes with in order to create your object.
Static factory methods don't have to consume more memory, but a constructor always does
One of the nice things (YES, it is nice) about using a static method to return an instance is that it could hand back an already created instance. This is something that constructors simply can't do. The best that a constructor can do is create a lightweight wrapper that wraps around a previously created massive object, but this is still consuming the tiny amount of memory for that wrapper.
There's all sorts of reasons we might want to hand back a previously created object rather than always returning a brand new object each time, but the biggest benefits can be:
"But wait! What if we wanted a mutable object instead? If you hand back a mutable object, then who knows if another thread is using it too! You could have race conditions!" Yep, don't do it. In that case, always hand back a new instance, or use some other fancy tricks I won't go into here.
Using constructors as the only means of creating an immutable object becomes tedious and confusing if the class has many fields
When it comes to those immutable objects, the constructors can get pretty gnarly sometimes, because if the field isn't initialized where it is declared, then the constructor has to assign a value to the field, otherwise the code will fail to compile. For example:
public class MutantAnimal {
private final int numArms;
private final int numLegs;
private final Species originalSpecies;
...more fields...
public MutantAnimal(int arms, int legs, Species species, ...params for other fields) {
numArms = arms;
numLegs = legs;
originalSpecies = species;
...other assignments...
}
}
Studies have shown that it is difficult for the average person to keep more than seven items in their head at any one time. The same goes for programmers and params. If you've tried calling a method with more than seven params, you know it isn't the most straightforward, even with the help of an IDE.
I bring this up because, for immutable objects, if all you allow to create that object are constructors, including that massive constructor, then other programmers using your code will not be pleased. You're closing off the potential for so many other ways to make it easier to build this class, including, but not limited to, static factory methods.
Another pattern we can use to reduce the number of params, and is actually my favorite for this scenario of creating a largish immutable object, is the builder pattern, but that's outside of the scope of this discussion.
And yes, there are even patterns available which can reduce the number of params you'd need to pass to the constructor, it depends on the situation. But why restrict ourselves to those patterns only, all so that we can keep using a constructor?
In fact, now that we have these other, easier ways of creating these large immutable classes, we don't even need to publicly expose that lengthy constructor at all! We could make it private, and force the creation of the class to only go through our static methods or our builders, which in turn would do the heavy lifting of calling the aforementioned private constructor. But we can leave the constructor public too if we like.
Using static factory methods to create or convert, instead of constructors, is more common than you think, and is already used in Java
There are several examples of this in the Java language already. Calendar.newInstance() is one. A better example is Long Long.valueOf(long value). I like using Long, Integer, Boolean, and the other boxed primitives here because they have several static method converters (and the constructor is still available). Long (and others) do exactly what I described in the previous points:
Static factory methods are recommended over constructors by Java experts
Effective Java, 2nd ed, Joshua Bloch, Item 1: "Consider static factories instead of constructors"
Yes, I know it isn't a valid argument to say "But these 'smart' people are doing it, we should too" because the answer, invariably, is "If they all jumped off a bridge, would you follow?" Well done. Check mate. Slow golf clap.
But, it wouldn't hurt to find out the reason behind why they're all jumping off of said bridge:
Summary
Constructors have their use, but don't go overboard with them. Use static factory methods instead, where possible, and consider other patterns to pure constructors.
I won't start with why static factory methods are good and when they should be used. Instead I'll start with the list of negatives about static factory methods that my friend provided, and discuss them one-by-one:
- Static factory methods do not fall into the constructor area of the JavaDoc therefore a user must read down the doc or code to find a method that constructs the class.
- A constructor is allowed to set variables directly at construction time. During this time if an overridable (non-final) method is used it will generate a warning.
- None of the restrictions or benefits of constructors are available.
- It is less efficient. It requires the memory for a static method but saves no time. A new class must still be constructed, and then extra steps are required to set each class variable. Assuming there are any optimizations for construction we get none of them.
- There is no way to enforce immutability.
- The calling method will not have the new keyword visible: Thing a = fromSomeOtherThing(
SomeOtherThing sot)
Static factory methods do not fall into the constructor area of the JavaDoc therefore a user must read down the doc or code to find a method that constructs the class
No disagreements there. I vaguely remember encountering this multiple times when starting out with Java, like with Calendar. I couldn't see how to create a Calendar easily, because when I used new Calendar() it was abstract and I'd need to fill in methods to make it work. Then I found out that I should use Calendar.getInstance(). Pretty easy after that, and as a bonus I didn't even need to know if what it created was a GregorianCalendar or something even more spiffy.
So yes, it is "hidden", but this happens so much in Java (for valid reasons) that it'll only trip up novices. Or, the class is so HUGE that it is buried in the JavaDoc or in the IDE autocomplete list. In that case, the class has other problems.
[Update: I saw some code from a different colleague who, instead of using Calendar.getInstance(), created a new GregorianCalendar. So there may be more to this point than I initally gave credit. Also: if you're coding in Java and the project allows it, stop using Date and Calendar and switch to the new date and time methods provided in Java 8, or use the JSR-310 backport if you're still stuck in Java 7 for whatever legitimate, but still lame, reason.]
A constructor is allowed to set variables directly at construction time. During this time if an overridable (non-final) method is used it will generate a warning.
But we can set fields with other methods, provided the field isn't final. And even if the field is final we can still modify it, providing the field isn't one of the primitives (int, double, boolean, etc) and the field's class provides setters. In Java, the only thing that final provides you as a field modifier is that it prevents you from pointing that field to a different object in a different memory location. (Yes, this means that just because a class's fields are all marked private final doesn't mean the class is truly immutable. You must also look at the type of each field: those too much also be all primitives or immutable classes (and are immutable all the way down). Only then is it considered immutable.)
The issue with why it is unsafe to call a non-final setter method from a constructor is because if the child class overrides the setter, then the parent class's variable might not get set if the overridden setter doesn't call super.setX() too.
The straightforward answer may be "then don't use setters in the ctor, set the values directly", but that is pretty tedious if the setter had some complex logic in it: that complex logic would need to be repeated in the ctor too, and if you change one, you'd need to remember to change the other. Thankfully, the solution is straightforward enough without resorting to copypasted code: put the complex logic into a private setXInternal(...) and have the ctor and the setter call into that. Granted, we can only do this if we still want the class to be mutable. If the class, or that field specifically, is to be immutable, then there's no choice but to use a constructor... but this can still be worked around somewhat. I'll explain later.
None of the restrictions or benefits of constructors are available
I'm not entirely sure what my friend was getting at here. We can still have the static factory method call the constructor if we wanted and get all them tasty restrictions and benefits. The thing is, sometimes we don't need the restrictions that a constructor has. With a static factory method, we could even return null to indicate a failure state (which I wouldn't advise doing, but this option is still available to those that want it).If the class was abstract, we could even implement the missing part we need, which the caller might actually like if they don't care what exact implementation of the class they get, as long as it adheres to the interface. This has a name of "static factory method" and it is widely used in the OO space, and it is beautiful. Admittedly, it can get overused if every class does this; simple constructors for simple classes are good enough.
I'm breaking the next one apart because it is several items:
it is a less efficient[sic].
In the basic case, yes, it is less efficient because instead of one call to make an object, it now requires two. But it can be more efficient, which I'll explain later.
It is less efficient. It requires the memory for a static method but saves no time. A new class must still be constructed, and then extra steps are required to set each class variable. Assuming there are any optimizations for construction we get none of them.
Okay, so the classloader part of memory has one extra method to store, which isn't a big deal. It consumes the same amount of memory whether there is one object instance in memory, or 5000. In other words, the memory load per object is zero.
As for saving time, true, in the basic case it saves no time because it is calling a constructor, which the caller could do directly. But it can be faster than constructors. I promise I'll answer this shortly!
A new class must still be constructed, and then an extra steps are required to set each class variable. Assuming there is any optimization for construction we get none of it.
Again, in the basic case, a new class must still be constructed. But since this static method is part of the class code, we could directly set the values if we wanted, but might as well use a constructor at that point anyway.
As for optimization for construction: because we're using setters here, and because I'm not privy to how "optimizy" the HotSpot VM will make a frequently called operation, I will agree that we lose out on the optimization because I have no idea what it would do.
There is no way to enforce immutability
True dat! It's the constructor's bread and butter. But we'll get back to immutability in a little bit, because believe it or not, that is where static factory methods can have the most benefit.
The calling method will not have the new keyword visible: Thing a = fromSomeOtherThing(SomeOtherThing sot)
I think the claim here is that...
Thing a = new Thing(sot);
Thing a = fromSomeOtherThing(sot);
The counterpoints...
Constructors can't have different names for one class, which might look funny if they all must do different things in order to return the instance.
Sure, you won't have any problem with your constructors if you only need to pass in different complex objects. You won't have any problem with these constructors:
public MutantAnimal(Dog dog) {
// make a mutant animal from a dog input
}
public MutantAnimal(Cat cat) {
// make a mutant animal from a cat input
}
But what if you need to take in animals from different serialized data, like this:
// Won't compile (and bad for other reasons anyway)
public MutantAnimal(String xml) {...}
public MutantAnimal{String json) {...} // ERROR!
Can't do it. If we MUST do this only with constructors, and not static factory methods, we can pull this ugly trick:
// Ugly and not recommended, but doable
// Handles both xml and json! Yay?
public MutantAnimal(String text, boolean isXml) {
if (isXml) {...}
else {...}
}
Gross. What if we want to handle yaml too? We could use an enum instead:
// Still ugly, still not recommended, but doable
public MutantAnimal(String text, SerializedType type) {...}
If we give up on the "everything is better as a constructor" idea and use static methods that know how to do the conversion for us, things become much more simple and straightforward:
// Better than the previous examples
public static MutantAnimal fromXml(String xml) {...}
public static MutantAnimal fromYaml(String yaml) {...}
public static MutantAnimal fromJson(String json) {...}
Notes: Before anyone goes off and creates their own fromXml/Yaml/Json methods, you should know that I created these as a simple example of how constructors can fail you if you want multiple constructors but one or more have the same parameter list. I wouldn't recommend anybody create these from... methods. Instead, go find a nice library like Jackson and use the features it comes with in order to create your object.
Static factory methods don't have to consume more memory, but a constructor always does
One of the nice things (YES, it is nice) about using a static method to return an instance is that it could hand back an already created instance. This is something that constructors simply can't do. The best that a constructor can do is create a lightweight wrapper that wraps around a previously created massive object, but this is still consuming the tiny amount of memory for that wrapper.
There's all sorts of reasons we might want to hand back a previously created object rather than always returning a brand new object each time, but the biggest benefits can be:
- speed, because we aren't wasting time allocating memory and then eventually GC'ing it, and
- less memory consumption.
"But wait! What if we wanted a mutable object instead? If you hand back a mutable object, then who knows if another thread is using it too! You could have race conditions!" Yep, don't do it. In that case, always hand back a new instance, or use some other fancy tricks I won't go into here.
Using constructors as the only means of creating an immutable object becomes tedious and confusing if the class has many fields
When it comes to those immutable objects, the constructors can get pretty gnarly sometimes, because if the field isn't initialized where it is declared, then the constructor has to assign a value to the field, otherwise the code will fail to compile. For example:
public class MutantAnimal {
private final int numArms;
private final int numLegs;
private final Species originalSpecies;
...more fields...
public MutantAnimal(int arms, int legs, Species species, ...params for other fields) {
numArms = arms;
numLegs = legs;
originalSpecies = species;
...other assignments...
}
}
Studies have shown that it is difficult for the average person to keep more than seven items in their head at any one time. The same goes for programmers and params. If you've tried calling a method with more than seven params, you know it isn't the most straightforward, even with the help of an IDE.
I bring this up because, for immutable objects, if all you allow to create that object are constructors, including that massive constructor, then other programmers using your code will not be pleased. You're closing off the potential for so many other ways to make it easier to build this class, including, but not limited to, static factory methods.
Another pattern we can use to reduce the number of params, and is actually my favorite for this scenario of creating a largish immutable object, is the builder pattern, but that's outside of the scope of this discussion.
And yes, there are even patterns available which can reduce the number of params you'd need to pass to the constructor, it depends on the situation. But why restrict ourselves to those patterns only, all so that we can keep using a constructor?
In fact, now that we have these other, easier ways of creating these large immutable classes, we don't even need to publicly expose that lengthy constructor at all! We could make it private, and force the creation of the class to only go through our static methods or our builders, which in turn would do the heavy lifting of calling the aforementioned private constructor. But we can leave the constructor public too if we like.
Using static factory methods to create or convert, instead of constructors, is more common than you think, and is already used in Java
There are several examples of this in the Java language already. Calendar.newInstance() is one. A better example is Long Long.valueOf(long value). I like using Long, Integer, Boolean, and the other boxed primitives here because they have several static method converters (and the constructor is still available). Long (and others) do exactly what I described in the previous points:
- Long is immutable
- Java has a LongCache which stores precreated versions of Long between -128 and 127, inclusively
- If the client calls Long.valueOf(10), then a new Long isn't created, a previously created one is handed back.
- If the client calls Long.valueOf(1000), then in that case, a new Long is always created.
- If the client calls new Long(10), then a new Long is always created, there is no way around it.
Static factory methods are recommended over constructors by Java experts
Effective Java, 2nd ed, Joshua Bloch, Item 1: "Consider static factories instead of constructors"
Yes, I know it isn't a valid argument to say "But these 'smart' people are doing it, we should too" because the answer, invariably, is "If they all jumped off a bridge, would you follow?" Well done. Check mate. Slow golf clap.
But, it wouldn't hurt to find out the reason behind why they're all jumping off of said bridge:
- A fire is consuming the bridge from both sides, the only escape is by water that is only 20 feet down, oh no!
- They're all taking turns jumping off, and it turns out they had a device called a "bungee cord" attached so that they wouldn't plummet to their death.
- Turns out some weird cosmic radiation made everybody invincible, and you and everybody else has jumped off of even more dangerous bridges with no harm.
- Fill in your own reason, it's fun!
Summary
Constructors have their use, but don't go overboard with them. Use static factory methods instead, where possible, and consider other patterns to pure constructors.
Monday, August 15, 2016
Building and Testing Tezad in Go 1.6 vs 1.7
Go 1.7 just got released! How does Tezad fair?
Tezad is pezad's puzzle game project, written in Go. It still has quite a lot of polishing ahead of it, but at least the game is playable (besides not knowing where the boundaries are). Take a look:
It's got lots of other stuff though: A game that ramps up gravity every 10 line clears; gravity which can drop 2 or more lines every frame towards the higher end, even instantly dropping to the bottom on the last levels; CW and CCW rotation, fast drop, instant drop, wall kicks, a ghost tetromino that will show where your tetromino will land... you can even hold tetrominoes too, it's just too bad you can't see what you're holding.
Go 1.7 supposedly has a compiler that will make smaller and faster binaries, and will do this faster than previous versions of Go. Let's try it out!
I can test the compile times and binary sizes easily enough, but the game doesn't yet have an automated benchmarking tool. What it does have is unit test for core parts of the game logic, all running parallel. So, I ran a bash script to build Tezad in a loop n times, and another script to loop over running the tests n times as well.
Turns out they weren't lying! Take a look:
As tested on an old 13-inch late 2009 MacBook with 2.26 GHz Intel Core 2 Duo, 4GB DDR3, Crucial M2 256GB SSD.
Build time improved over 9%, size of the binary improved over 10%, and the time to run the tests improved over 24%. Not too shabby for not changing a single line of code!
(As an aside, you may be wondering what happened to Tezad since you saw it around 2010 or so. That was the C++ version. The new one is a complete rewrite. Code isn't yet available to the public, but someday it should be.)
Tezad is pezad's puzzle game project, written in Go. It still has quite a lot of polishing ahead of it, but at least the game is playable (besides not knowing where the boundaries are). Take a look:
 |
| The latest version of Tezad, built on Go 1.7. Look at me almost get a home run, or a quadruple, or whatever the non-infringing name would be! |
Go 1.7 supposedly has a compiler that will make smaller and faster binaries, and will do this faster than previous versions of Go. Let's try it out!
I can test the compile times and binary sizes easily enough, but the game doesn't yet have an automated benchmarking tool. What it does have is unit test for core parts of the game logic, all running parallel. So, I ran a bash script to build Tezad in a loop n times, and another script to loop over running the tests n times as well.
Turns out they weren't lying! Take a look:
| Go Version | 1.6 | 1.7 | diff | ratio |
| Total build time sec | 63.283 | 57.426 | -5.857 | 90.74% |
| Total builds | 25 | 25 | 0 | 100.00% |
| Avg build time sec | 2.53132 | 2.29704 | -0.23428 | 90.74% |
| Tezad size bytes | 5055696 | 4531984 | -523712 | 89.64% |
| Tezad size MiB | 4.821487427 | 4.322036743 | -0.4994506836 | 89.64% |
| Total test time sec | 91.836 | 70.13 | -21.706 | 76.36% |
| Total tests | 25 | 25 | 0 | 100.00% |
| Avg test time sec | 3.67344 | 2.8052 | -0.86824 | 76.36% |
Build time improved over 9%, size of the binary improved over 10%, and the time to run the tests improved over 24%. Not too shabby for not changing a single line of code!
(As an aside, you may be wondering what happened to Tezad since you saw it around 2010 or so. That was the C++ version. The new one is a complete rewrite. Code isn't yet available to the public, but someday it should be.)
Monday, March 7, 2016
FLIF - Free Lossless Image Format
FLIF is a lossless image format which "outperforms PNG, lossless WebP, lossless BPG, lossless JPEG2000, and lossless JPEG XR
in terms of compression ratio."
Besides being patent-free and LGPL licensed, one of the more useful features is in the interlaced images. Need a 1:2 or 1:4 sized image? Then don't read all of the file! I'm not sure if there are markers in the file which let you find out these boundaries, but it is a new file format so who knows what'll happen between now and version 1.0.
Besides being patent-free and LGPL licensed, one of the more useful features is in the interlaced images. Need a 1:2 or 1:4 sized image? Then don't read all of the file! I'm not sure if there are markers in the file which let you find out these boundaries, but it is a new file format so who knows what'll happen between now and version 1.0.
Monday, February 22, 2016
OpenDyslexic font
OpenDyslexic font is designed to make text easier to read for dyslexics. Neat! It is also free for personal and commercial use.
http://opendyslexic.org/
http://opendyslexic.org/
Saturday, October 31, 2015
Online Rich Text Editors
Salesforce.com recently open-sourced Quill, a new entry into the "online rich text editor" category. I only took a quick glance at it; it looks clean and useful, with just enough features that I would consider it for future projects.
I've been wanting something else other than TinyMCE, but the ones I've looked at have lacked one vital function or another which either comes with TinyMCE or can be enabled with a plugin. I still have yet to find one I've liked, but they're either too bloated, or look like they're stuck in the early 2000's MS-Office theme.
The only problem I have with Quill at this point is that, based on my quick glance, one can't specify the type of text being entered, i.e. header, sub-header, paragraph, etc. But it can be faked with specifying Large, Small, Normal sizes, and choosing different fonts. I'd really like the former, though.
I've been wanting something else other than TinyMCE, but the ones I've looked at have lacked one vital function or another which either comes with TinyMCE or can be enabled with a plugin. I still have yet to find one I've liked, but they're either too bloated, or look like they're stuck in the early 2000's MS-Office theme.
The only problem I have with Quill at this point is that, based on my quick glance, one can't specify the type of text being entered, i.e. header, sub-header, paragraph, etc. But it can be faked with specifying Large, Small, Normal sizes, and choosing different fonts. I'd really like the former, though.
Sunday, September 13, 2015
Fixing "you need to install the legacy Java SE 6 runtime." errors
For various reasons I wanted to try out Universal Media Server on my MacBook OS X Yosemite 10.10.5 before I install it for real on my Linux box. However, this was not as easy as I thought it would be, because upon starting the app, an error window appears with the text "you need to install the legacy Java SE 6 runtime."
Yes, doing that would have been the easy fix, but the legacy Java SE 6 runtime is old, with many known security exploits, and I already have the latest JDK8 installed, why can't I just use that?
This process was not as straightforward as expected, but easy enough, explained at http://stackoverflow.com/a/19594116:
Yes, doing that would have been the easy fix, but the legacy Java SE 6 runtime is old, with many known security exploits, and I already have the latest JDK8 installed, why can't I just use that?
This process was not as straightforward as expected, but easy enough, explained at http://stackoverflow.com/a/19594116:
- Make sure Java is up to date.
- Edit the Info.plist file (I did this via command line):
- sudo vi /Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Info.plist
- In the "JVMCapabilities" array, make sure it has the three following entries:
-
JNI
BundledApp
CommandLine - Link a dynamic library:
- sudo mkdir -p /Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home/bundle/Libraries/
- sudo ln -s /Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home/jre/lib/server/libjvm.dylib /Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home/bundle/Libraries/libserver.dylib
- Reboot.
Saturday, September 12, 2015
Static Analysis
I listened to Floss Weekly podcast episode #352 - FWKNOP earlier this week. In it, the guest mentioned two tools he uses for static analysis: CLANG static analyzer (which, as the name suggests, is only for C/C++ and Objective-C) and the powerful Coverity Scan tool, which is free for open source projects and covers other languages as well.
Friday, September 11, 2015
IPFS
IPFS is short for InterPlanetary File System, a peer-to-peer filesystem. Peers have a choice in what they distribute, unlike Freenode.
Say you want to store a file on IPFS. The unique name is basically a hash of the contents of the file. If the contents change by even one bit, then a completely new hash is made. In one way, this is a good thing because it allows others that care about said content to be able to archive it and distribute it themselves, and others can easily determine if the file they got was altered in some way by hashing it again, and comparing it with the name.
However, what this means is that we can't ever change the file, even if we wanted to change it. IPFS's answer to it is similar to what bitcoin does for wallets, which is to use a public key hash. They call this IPNS, or InterPlanetary Naming System. So we could sign a file with our private key, and people who know our Peer ID can retrieve it, using the public key to verify that the new contents were, in fact, mutated by us. The IPFS folks have a better explanation on their site.
IPFS, written in go, is being used by NeoCities to spearhead their permanent, distributed web movement. While it is usable now, the technology is very much a work in progress. It has stirred up Hacker News a few times in the past, and I'm sure we'll see more of them.
I've been looking for some sort of peer-to-peer filesystem like this for maps, chatrooms, achievements, save games, replays, app updates, rankings, etc. While I don't think IPFS is the answer for all of those use cases, it does work nicely for maps and app updates, at least. The end goal would be an online game where everybody can contribute any amount of their own resources to ensure that the game runs smoothly, and beneficial contributors are rewarded, detrimental users are punished, and it all somehow (and magically) happens without mob rule (all the players ganging up on a few users) yet without a tyrannical ruler (the author of game) either. I've touched on all this before so I'll save mybreath fingers from blistering.
Say you want to store a file on IPFS. The unique name is basically a hash of the contents of the file. If the contents change by even one bit, then a completely new hash is made. In one way, this is a good thing because it allows others that care about said content to be able to archive it and distribute it themselves, and others can easily determine if the file they got was altered in some way by hashing it again, and comparing it with the name.
However, what this means is that we can't ever change the file, even if we wanted to change it. IPFS's answer to it is similar to what bitcoin does for wallets, which is to use a public key hash. They call this IPNS, or InterPlanetary Naming System. So we could sign a file with our private key, and people who know our Peer ID can retrieve it, using the public key to verify that the new contents were, in fact, mutated by us. The IPFS folks have a better explanation on their site.
IPFS, written in go, is being used by NeoCities to spearhead their permanent, distributed web movement. While it is usable now, the technology is very much a work in progress. It has stirred up Hacker News a few times in the past, and I'm sure we'll see more of them.
I've been looking for some sort of peer-to-peer filesystem like this for maps, chatrooms, achievements, save games, replays, app updates, rankings, etc. While I don't think IPFS is the answer for all of those use cases, it does work nicely for maps and app updates, at least. The end goal would be an online game where everybody can contribute any amount of their own resources to ensure that the game runs smoothly, and beneficial contributors are rewarded, detrimental users are punished, and it all somehow (and magically) happens without mob rule (all the players ganging up on a few users) yet without a tyrannical ruler (the author of game) either. I've touched on all this before so I'll save my
Monday, September 7, 2015
Steven Wittens, and the Pixel Factory
Steven Wittens, the man behind acko.net, recently gave a presentation called "The Pixel Factory". This man has put more thought into rendering his website's header than many programmers (yours truly included) have put into entire games. Even the presentation itself reveals a level of quality and polish few others achieve. It's a good introduction into several rendering concepts, and even presents a few different views of said concepts.
Some of the items that came up were new to me but have been used in the field for quite some time, such as drawing text with signed distance fields in order to keep text looking sharp when it appears distant/small.
It also pointed me to WebGL Stats, which, as is said in the name, shows statistics of various web API and WebGL extensions support.
Order-independent transparency in WebGL vs. OpenGL was touched on as well (with WebGL 1.0, it must be two-pass). The original way to do transparency in OpenGL was to order the triangles/geometry back-to-front and disable writing to the depth-buffer so that each transparent object is drawn. With order-independent transparency, the fragments themselves are sorted.
Some of the items that came up were new to me but have been used in the field for quite some time, such as drawing text with signed distance fields in order to keep text looking sharp when it appears distant/small.
It also pointed me to WebGL Stats, which, as is said in the name, shows statistics of various web API and WebGL extensions support.
Order-independent transparency in WebGL vs. OpenGL was touched on as well (with WebGL 1.0, it must be two-pass). The original way to do transparency in OpenGL was to order the triangles/geometry back-to-front and disable writing to the depth-buffer so that each transparent object is drawn. With order-independent transparency, the fragments themselves are sorted.
Subscribe to:
Posts (Atom)