This has the side effect of loosing the stack trace if I break on "uncaught exceptions", and breaking on "all exceptions" is absolutely no option, since many frameworks use the exception handling as mechanisms of detecting various features of the browser environment.
Thus I came up with this pattern:
So if an exception happens, I can still break on all exceptions, but also get my log right.
Can you imagine how cool it would be to chain exceptions like in Java? For example:
At least we can dream about it, and appreciate more languages that do offer chaining of exceptions.
An interesting article is making waves on dzone and twitter:
TL;DR: the sun.misc.* package it's going to be removed, a bunch of libraries are using it, apocalypse will ensue, just because Oracle removes packages for "no reason". (I kid you not, the dripstat author actually states that).
No it's not a new thing. No it's not the apocalypse now either. Let's break it down on why:
1. It's not at all a "no reason" change
It's because Java has become so full of security exploits, it's not even funny at this moment. It's scary to see how in January a patch fixed 19 security holes, with 13 of them being show stoppers. Oracle themselves explains it at length even.
It's not because:
"This engineer hates the Unsafe class for no real reason at all.."
That's a silly statement, to say the least. (To be honest, I get my blood boiling a bit just reading that sentence, because it's insulting to the engineer)
It is because people are loosing trust in the platform. Why would you go with a platform ridden with bugs like that? What's the point in using whatever framework that is allegedly super secure, if the JVM itself it's the weakest link. That is what makes Java now loose billions.
That's the reason why Apple dropped Java altogether, because its security was in the gutter.
2. It's a private package of the JVM
If you're bold enough to use it, you should be bold enough to write your own thing. Why should Oracle be bound by some form of moral requirement to document some whatever cryptic legacy code, that people reverse engineered in the first place? What. The. Hell.
Probably this tweet captures the essence of the whole thing:
"OMG, we've been stupid and used a private API for years, now it's being removed… what do we do? BLAME ORACLE!" http://t.co/P9D9kW6CrF— Michael Klishin (@michaelklishin) July 14, 2015
It's not even such a big deal. I swear!
Do you know what else introduced breaking API changes for public APIs? The endorsed folder. It's what stuff like WebLogic uses to overwrite already published public APIs. I'm going to reiterate this: There is already the endorsed folder, that allows overwriting public APIs from the JVM, and people are using it. This is a great thing actually, especially if the API was not finalized. Why getting stuck with an API for the next two years?
Public APIs! And you see that the universe imploded? Billions of dollars were lost? Calm down people, jeeeez.
3. There will still be YEARS of Java 8 support
Oracle doesn't just throw away JVMs, and then just plugs support out. If the program you're using, and its creepy library that needs the sun.misc.Unsafe are that important, go buy support. I mean, for crying out loud, you can still get Java 6 support that people were using to connect to dinosaurs. And the Java life cycle support it's for 11 (eleven!!) years.
So finally, please all, can you just chill out?
It's all for the better I promise.
PS: I am not affiliated with Oracle in any shape or form, beside I'm developing and using Java, and I'm a certified JEE5 Enterprise Architect.
Do you want your editing of AsciiDoc (or Markdown) to look like this?
In order to get AsciiDoc support working nicely in VIM, you'll need a couple of things:
Then add another syntax file for AsciiDoc, by creating another plugin, with just the /syntax folder in it. (If you use pathogen, it should look something like this: https://github.com/bmustiata/vim/tree/master/bundle/zzzciplogic). In it configure your SyntaxRange plugin for matching for various languages:
The gherkin one, is there separately, since for the gherkin language, we're going to use the cucumber syntax file.
Since the SyntaxRange registration it's in the syntax file, it will only activate when editing asciidoc files.
PS: I inspired for the SyntaxRange calls from here: https://github.com/dahu/vim-asciidoc/blob/master/syntax/asciidoc.vim, but I just rewrote the RegExp to better match the start of the source.
PS2: For doing live html visualising of the file, you can use fast-live-reload:
Then just open the http://localhost:9000/test.html in the browser and watch it change as you save.
Whenever talking to each other, whenever that happens, developers tend to formalize specific concepts and map them to specific words.
For example you all know what a singleton is. We don't need to disambiguate in regards to it. Nor do we need to disambiguate in regards to what an object, function, or method are.
And this is why the following article A Factory Should Create, Not Retain, in which Paul M. Jones claims that a factory that retains references to its created instances it's not truly a factory, came as a surprise for me.
The article TL;DR: A factory just creates objects, a registry just references objects, a container does both.
But while this might be technically correct, it's not actually meaningful in any way to make this distinction, except tedious mental exercise. Don't worry, here come examples (Java, but, you get the picture).
1. Caching factories are containers
In java numbers can be represented as either primitives, either immutable objects. To convert from one another, e.g. from `int` to `Integer`, the Integer class has a factory function named: `valueOf(int) : Integer`. This makes the Integer class a factory for Integer objects.
Except that I lied a bit.
Creating objects for every number it's expensive, and since the low indexes are heavily used, they are pre-cached (at least in the Oracle's Java version they are). This is not part of the functional specification, it's just an implementation detail, on how the objects are going to be fetched. Note that objects outside that range are always created.
Can you be pedantic and say, that this is a container, and not actually a factory? Yes. Does it add value to the conversation? No. I'm going later to explain why this is an issue.
Note that if I just comment those caching lines, my container magically transforms to a factory, and if I uncomment it, it's back a container, even if functionally its behaviour is the same. But whatever.
By the same definition...
2. Registries that create objects are containers as well
Again in java there is an amazing class, named TreeMap. TreeMap holds instances to these objects into a tree structure, thus its full of imagination name of TreeMap. Tree ... Map. TreeMap.
Someone could argue that this is a registry, but again, if we want to be pedantic about it, this is no ordinary registry. Because it creates its keys, so it's also a factory.
Among the many separation of concerns that this class blatantly violates, are also creating and reordering objects, but for the sake of our discution, we can safely say that the TreeMap is technically also a factory, since it creates its keys:
Finally, I said that I will explain why I find it as an issue, with being pedantic about separation of concerns. Because it stiffles communication. We actually lose more time trying to disambiguate things that our so specific vocabulary would allegedly try to disambiguate.
The best example is Singleton.
Singleton it's a pattern that describes how single instances can be created for an application. This is made by having a single static instance on the class, and using it across the application.
Except that this is not true if you use Dependency Injection. The singleton class will not have the single instance bound to the class. It will not implement the actual pattern. Actually might not even be a singleton in certain cases, since now this might be a configuration issue. So I should not use the "singleton" word to describe it at all, since it's not implementing the pattern, nor can I guarantee that it will always be a singleton.
But that's why this whole thing makes no sense. If I know that in my application an object has a single instance (provided by the DI, or its own static reference, or the JVM that creates it via some callback method, etc), then I can say it is a singleton. Its meaning is derived from its behavior, not the actual implementation on how the singleton behavior will be provided. That is an implementation detail.
Similarily, if I have an object that creates other objects as one of its main purposes in life, it is a factory, irrespective on what kind of caching (if any it uses). It's meaningless to say that valueOf from Integer is actually a container method. There is no gained value out of it.
If an object is used to mainly store references to other objects, then yes, it's a registry. The same goes on key creation. This doesn't changes the purpose of the class.
It makes no sense looking at every tidbit of implementation details, with super categorization. There is no benefit out of it. No cleaner code, no better communication. Nothing.
We can't see the forest anymore, since so many trees are blocking our view.
Since I don't want eye strain, and have a mild OCD, I want the same font and sizes across all the monospaced text editors that I am using.
The font I decided in using is Ubuntu Mono with some patches to look good on my vim. It's a regular truetype font.
Turns out that IDEA and Visual Studio Code think that the font size should be 16 Pointy Thinigies, while GVim and the terminal would rather go for 12 Pointy Thingies, to render a text with the exact same size in pixels.
Good job Linux.
The one to rule them all. The browsers that is.
SharpKnight is an Android chess game.
MagicGroup is an eclipse plugin.