A hipster software rant

I have been called a hipster many a times and that is because I don't really like mainstream things and, instead, choose to see beauty and purpose somewhere else. I'm not really a hipster, though, since the trends I am following are not the latest and I have no sense of fashion. But enough about me. Let's talk about software and it's latest incarnation: mobile and HTML5/javascript and how I despise the hype around something that is, let's put it simply, a combination of lazy programming and market forces. No real innovation, no quality, no soul. A Hollywood of software, if you will.

People, I've seen this before and so have you. There was a time when computing was done on devices that had single digit megahertz chips at their core. Applications and games thrived. Programmers would always complain about the lack of resources and there was a time when 64KB of memory was thought enough for most computing purposes. It was that time that spawned the algorithmic generation, the guys that usually ask you what a graph is or how to manually do a bubble sort on paper when they hire you to work on web sites. You needed to make your software slim and efficient to work on those devices. Then the processor power, memory and drive capacity just exploded. Each step of the way, applications and games thrived. The problem was... they were the same as before, only larger. Wolfenstein became Doom became Quake became Counter Strike became Call of Duty and beyond, the resolution, the realism, the environment ever evolving, but the game staying the same: get some guns and kill something. But still, it was OK, we like things bigger, we want more pixels. It doesn't matter that the Windows operating system grows exponentially to use the increasing space and processing power, yet we use it in about the same way as before. It doesn't matter that the single player games just look better and have the same or even less complexity than the games ten years before. It's a status quo we can live with.

But then browsers came along. Suddenly, there is a whole new market: online apps. One server to bind them all. And we again lament the lack of resources, as we use slow javascript and try the ever annoying Java applets and somehow we settle on Flash. It can be used on any operating system, almost any browser, let's make games with it and place them online. The only reason we do not make entire web sites in Flash remaining SEO. And we lament the lack of programming tools for something that was originally created only for online animation for commercial ads, but we can live with it. All the games we played so joyfully on 80386 processor machines we can now play in a browser, in Flash, on machines that are 100 times faster. No problem there.

Then the smartphones and tablets arrived, with their new operating systems, their weird resolutions and their direct dislike of Flash. Suddenly Flash is no good anymore: it is not open enough, not fast enough, not compatible enough. Instead, let's switch to HTML5 and Javascript, the backbone of the Web. Let's use those. Sure, now we need a faster Javascript, so we think on it a little and Kaboom! Javascript is suddenly 8 times faster. We need new HTML concepts and ideas and Kapow! the HTML standard suddenly changes after years of wallowing between panels and committees. Nothing can stand in the way of change now, we even have portable devices that are faster than the computers we used 10 years ago.

And so we get to today, when my Athlon II 2500+ computer is too slow to play flash games without overheating, because they are made with frameworks designed to output HTML and Javascript. And that is why I can't even move the mouse in browser based HTML5 and Javascript games, even if what the page I am on only wants to do is let me play Angry Birds, a game that would have worked fine, with almost the same level of graphics and certainly the same level of intelligence and entertainment, on a 33Mhz computer from 20 years ago.

I could live with all that, though. I could buy another computer, after all it is a wonder this one even works anymore, but it bothers me so much that I have games and films and software that have been working on this machine for so long and they are mostly better than what I can find today. It bothers me to buy a smartphone or a tablet only to see my rights to use it restricted and conditioned from the people that make them. It bothers me to have lived 20 years with computers, only to have more pixels at the end. I can even imagine my LCD coffin, being put into the ground, with people crying over the touching (really, you can touch them!) floating images from it, while some people would discuss the number of pixels the coffin has. He lived a good life, he got pixels.

Read More

The Checklist Manifesto, by Atul Gawande

I think that The Checklist Manifesto is a book that every technical professional should read. It is simple to read, to the point and extremely useful. I first heard about it in a Scrum training and now, after reading it, I think it was the best thing that came out of it (and it was a pretty awesome training session). What is this book about, then? It is about a surgeon that researches the way a simple checklist can improve the daily routine in a multitude of domains, but mainly, of course, in surgery. And the results are astounding: a two fold reduction in operating room accidents and/or postoperatory infections and complications. Atul Gawande does not stop there, though, he uses examples from other fields to bring his point around, focusing a lot on the one that introduced the wide spread use of checklists: aviation.

There is a lot to learn from this book. I couldn't help always comparing what the author had to say about surgery with the job I am doing, software development, and with the Scrum system we are currently employing. I think that, given he would have heard of Scrum and the industrial management processes it evolved from, Gawande would have surely talked about it in the book. There is no technical field that could not benefit from this, including things like playing chess or one's daily routine. The main idea of the book is that checklists take care of the simple, dumb things that we have to do, in order to unclutter our brain for the complex and intuitive work. It enables self discipline and allows for unexpected increases in efficiency. I am certainly considering using in my own life some of the knowledge I gained, and not only at the workplace.

What I could skim from the book, things that I marked as worthy to remember:

• Do not punish mistakes, instead give more chances to experience and learning - this is paramount to any analytical process. The purpose is not to kill the host, but to help it adapt to the disease. Own your mistakes, analyse them, learn from them.
• Decentralize control - let professionals assume responsibility and handle their own jobs as they know best. Dictating every action from the top puts enormous pressure on few people that cannot possibly know everything and react with enough speed to the unpredictable
• Communication is paramount in managing complex and unexpected situations, while things like checklists can take care of simple and necessary things - this is the main idea of the book, enabling creativity and intuition by checking off the routine stuff
• A process can help by only changing behaviour - Gawande gives an example where soap was freely given to people, together with instructions on how and when to use it. It had significant beneficial effects on people, not because of the soap per sé, but because it changed behaviour. They were already buying and using soap, but the routine and discipline of soap use was the most important result
• Team huddles - like in some American sports, when a team is trying to achieve a result, they need to communicate well. One of the important checks for all the lists in the book was a discussion between all team members describing what they are about to do. Equally important is communicating during the task, but also at the end, where conclusions can be drawn and outcomes discussed
• Checklists can be bad - a good checklist is precise, to the point, easy to use. A long and verbose list can impede people from their task, rather than help them, while vague items in the lists cause more harm than good
• A very important part of using a checklist system is to clearly define pause points - they are the moments at which people take the list and check things from it. An undefined or vaguely defined pause point is just as bad as useless checklist items
• Checklists are of two flavours - READ-DO, like a food recipe, with clear actions that must be performed in order, and DO-CONFIRM, where people stop to see what was accomplished and what is left to do, like a shopping list
• A good checklist should optimally have between five and nine items - the number of items the human brain can easily remember. This is not a strong rule, but it does help
• Investigate failures - there is no other way to adapt
• A checklist gotcha is the translation - people might make an effort to make a checklist do wonders in a certain context, only to find that translating it to other cultures is very difficult and prone to errors. A checklist is itself subject to failure investigation and adaptation
• Lobbying and greed are hurting us - a particularly emotional bit of the book is a small rant in which the author describes how people would have jumped on a pill or an expensive surgical device that would have brought the same great results as checklists, only to observe that people are less interested in something easy to copy, distribute and that doesn't bring benefits to anyone except the patients. That was a painful lesson
• The star test pilot is dead - there was a time when crazy brave test pilots would risk their lives to test airplanes. The checklist method has removed the need for unnecessary risks and slowly removed the danger and complexity in the test pilot work, thus destroying the mythos. That also reduced the number of useless deaths significantly.
• The financial investors that behave most like airline captains are the most successful - they balance their own greed or need for excitement with carefully crafted checklists, enabling their "guts" with the certainty that small details were not missed or ignored for reasons of wishful thinking
• The Hudson river hero(es) - an interesting point was made when describing the Hudson river airplane crash. Even if the crew worked perfectly with each other, keeping their calm in the face of both engines suddenly stopping, calming and preparing the passengers, carefully checking things off their lists and completing each other's tasks, the media pulled hard to make only the pilot a hero. Surely he denied it every time and said that it was a crew effort because he was modest. Clearly he had everything under control. That did not happen and it also explains why the checklist is so effective and yet so few people actually employ it. We dream of something else
• We are not built for discipline - that is why discipline is something that enables itself. It takes a little discipline to become more disciplined. A checklist ensures a kind of formal discipline in cases previously analysed by yourself. It assumes control over the emotional need for risk and excitement.
• Optimize the system, not the parts - it is always the best choice to look at something as a whole and improve it as a whole. The author mentions an experiment of building a car from the best parts, taken from different companies. The result was a junk car that was not very good. The way the parts interact with one another is often more important than individual performance

I am ending this review with the two YouTube videos on how to use and how not to use the WHO Surgical Safety Checklist that Atul Gawande created for surgical team all around the globe.

Read More

Resource class works only for some languages in ASP.NET class

I had a pretty strange bug to fix. It involved a class used in a web page that provided localized strings, only it didn't seem to work for Japanese, while French or English or German worked OK. The resource class was used like this: AdminUIString.SomeStringKey, where AdminUIString was a resx file in the App_GlobalResources folder. Other similar global resource resx classes were used in the class and they worked! The only difference between them was the custom tool that was configured for them. My problem class was using PublicResXFileCodeGenerator from namespace Resources, while the other classes used the GlobalResourceProxyGenerator, without any namespace.

Now, changing the custom tool did solve the issue there, but it didn't solve it in some integration tests where it failed. The workaround for this was to use HttpContext.GetGlobalResourceObject("AdminUIString", "SomeStringKey").ToString(), which is pretty ugly. Since our project was pretty complex, using bits of ASP.Net MVC and (very) old school ASP.Net, no one actually understood where the difference stood. Here is an article that partially explains it: Resource Files and ASP.NET MVC Projects. I say partially, because it doesn't really solve my problem in a satisfactory way. All it says is that I should not use global resources in ASP.Net MVC, it doesn't explain why it fails so miserable for Japanese, nor does it find a magical fix for the problem without refactoring the convoluted resource mess we have in this legacy project. It will have to do, though, as no one is budgeting refactoring time right now.

So, if the resource class doesn't seem to function for certain languages, even if the resx files exist, look at the custom tool and, after reading the above link, make a decision on how to fix it.

Read More

The Latvian Gambit

I've stumbled upon the Latvian Gambit and wanted to test it immediately against my colleagues. As you will see in the video, it seems a wonderfully aggressive opening, something akin to Shock and Awe, riddled with traps against your opponent. The truth is that it is an unprincipled opening, abandoning material advantage in the hope that your adversary will slip up and expecting you to have the skills to attack and defend accurately as the game progresses. I did manage to capture the queen once, but only after pointing out to my opponent that he could have forked my king and rook, so that the trap would work - he hadn't noticed. In the rest of the games, none of them running the course of the video you will see, the lack of skill on both sides of the table forced me to abandon this gambit for now, instead looking for something more principled and more appropriate for my playing level.

So here is the game from TheChessWebsite:

I've experimented with chess engines and watched other videos about the gambit and constructed a rather complex PGN file. You can play with it here. Don't forget to click on the variations to see how the game could progress. There is even a full game there, from a video that has the link in the comment.
[Event "The Latvian Gambit"]
[Site "Siderite's Blog"]
[Date "2012.04.18"]
[Round "?"]
[White "Siderite"]
[Black "Siderite"]
[Result "0-1"]
[BlackElo "2400"]
[ECO "C63"]
[Opening "Spanish"]
[Time "13:45:38"]
[Variation "Schliemann, 4.Nc3 fxe4 5.Nxe4 Nf6"]
[WhiteElo "2400"]
[TimeControl "0+60"]
[Termination "normal"]
[PlyCount "11"]
[WhiteType "human"]
[BlackType "human"]

1. e4 e5 2. Nf3 f5 3. Nxe5 (3. Bc4 3. .. fxe4 4. Nxe5 Nf6 (4. .. Qg5 5. d4
Qxg2 6. Qh5+ g6 7. Bf7+ Kd8 8. Bxg6 Qxh1+ 9. Ke2 c6) (4. .. d5 5. Qh5+ g6
6. Nxg6 hxg6 7. Qxg6+ (7. Qxh8 Kf7 8. Qd4 Be6 9. Bb3 Nc6 10. Qe3 Bh6 11. f4
Nge7) 7. .. Kd7 8. Bxd5 Nf6 9. Nc3 Qe7) 5. Nf7 Qe7 6. Nxh8 d5 7. Be2 (7.
Bb3 Bg4 {White loses the queen, one way or another} 8. f3 exf3+ 9. Kf2 Ne4+
10. Kf1 (10. Kg1 f2+ 11. Kf1 Bxd1) 10. .. fxg2+ 11. Kxg2 Bxd1)) (3. Nc3 3.
.. Nf6 {Continue as for the king gambit (reversed)}) (3. exf5 3. .. e4 4.
Ne5 Nf6 5. Be2 d6 6. Bh5+ Ke7 7. Nf7 Qe8 8. Nxh8 Qxh5 9. Qxh5 Nxh5) (3. d4
fxe4 4. Nxe5 Nf6 5. Bg5 d6 6. Nc3 dxe5 7. dxe5 Qxd1+ 8. Rxd1 h6 9. Bxf6
gxf6) 3. .. Qf6 (3. .. Nc6 4. Qh5+
{https://www.youtube.com/watch?v=lZHGgEGM6SQ} (4. Nxc6 bxc6 5. exf5 Nf6 6.
d4 d5 7. Bd3 Bd6 8. Be3 O-O 9. Nd2 Rb8 10. Rb1 Qe7 11. O-O h5 12. Nf3 Ne4
13. Bxe4 dxe4 14. Ng5 Bxf5 15. Qxh5 Rf6 16. Nh3 Qd7 17. Bg5 g6 18. Qh4 Rf7
19. Nf4 Rh7 20. Qg3 Kg7 21. Qc3 Rbh8 22. d5+ Kg8 23. h3 {correct move dxc6}
Bxh3 24. Qxc6 (24. Nxh3 Rxh3 25. gxh3 Rxh3) 24. .. Bf5 25. Nh3 Bxh3 26. Bf6
Bxg2 {Bh2+ would have been mate in 4} (26. .. Bh2+ 27. Kxh2 Bxg2+ 28. Kg3
Rh3+ 29. Kxg2 Qg4#) 27. f4 Qxc6 28. dxc6 Bf3 29. b4 Bxf4 30. Rbe1 Rh1+ 31.
Kf2 R8h2#) 4. .. g6 5. Nxg6 (5. Nxc6 dxc6) 5. .. Nf6 6. Qh4 Rg8 7. Nxf8 Rg4
8. Qh6 Rxe4+ 9. Kd1 (9. Be2 Nd4 10. Nc3 Nxe2 11. Nxe2 Qe7) 9. .. Ng4) (3.
.. Bc5 4. exf5 Bxf2+ 5. Kxf2 Qh4+ 6. Kf3 (6. Kg1 6. .. Qd4#) (6. Ke2 6. ..
Qe4+) (6. g3 Qd4+ 7. Kg2 Qxe5 8. Nc3 Qxf5 9. Bd3 Qf7 10. b3 Nf6 11. Re1+
Kd8 12. Qf3 Nc6 13. Ne4 Qe7 14. Nxf6 Qxf6 15. Qxf6+ gxf6 16. Bb2) 6. .. Nf6
(6. .. Ne7 7. Nc3 d6 8. g3 Qh5+ 9. g4 Qh4 10. Qe1 Qxe1 11. Bb5+ Nbc6 (11.
.. c6 12. Rxe1 cxb5 13. Nd3 Nc6 14. Nxb5) 12. Rxe1 dxe5 13. Rxe5 O-O 14.
Re4 h5 15. h3 Nxf5 16. Bc4+ Kh7 17. gxf5 Bxf5 18. Kg2 Bxe4+ 19. Nxe4 Rae8)
(6. .. b5)) (3. .. fxe4 4. Qh5+ g6 5. Nxg6 Nf6 6. Qe5+) (3. .. d6 4. Qh5+
g6 5. Nxg6 Nf6 6. Qh4) 4. Nc4 (4. d4 d6 5. Nc4 fxe4 6. Nc3 Qg6 7. f3 exf3
8. Qxf3 Nc6 9. Bd3 Qg4) 4. .. fxe4 5. Nc3 Qf7 (5. .. Qg6 6. d3 exd3 7. Bxd3
Qxg2 8. Be4 Qh3 {At this point black has not developed and is lost}) 6. d4
(6. Nxe4 d5) 0-1



Update: Here is another analysis of the Latvian Gambit, by Abby Marshall.
Roman Dzindzichashvili considers the Latvian gambit a sign of mental illness.
Chessexplained also has a video about it.

Read More

Refactoring: Improving the Design of Existing Code, by Martin Fowler, Kent Beck, John Brant, William Opdyke, Don Roberts

It was long overdue for me to read a technical book and I've decided to go for a classic from 1999 about refactoring, written by software development icons as Martin Fowler and Kent Beck. As such, it is not a surprise that Refactoring: Improving the Design of Existing Code feels a little dated. However, not as much as I had expected. You see, the book is trying to familiarize the user with the idea of refactoring, something programmers of these days don't need. In 1999, though, that was a breakthrough concept and it needed not only explained, but lobbied. At the same time, the issues they describe regarding the process of refactoring, starting from the mechanics to the obstacles, feel as recent as today. Who didn't try to convince their managers to allow them a bit of refactoring time in order to improve the quality and readability of code, only to be met with the always pleasant "And what improvement would the client see?" or "are there ANY risks involved?" ?

The refactoring book starts by explaining what refactoring means, from the noun, which means the individual move, like Extract Method, to the verb, which represents the process of improving the readability and quality of the code base without changing functionality. To the defense of the managerial point of view, somewhere at the end of the book, authors submit that big refactoring cycles are usually a recipe for disaster, instead preaching for small, testable refactorings on the areas you are working on: clean the code before you add functionality. Refactoring is also promoting software testing. One cannot be confident they did not introduce bugs when they refactor if the functionality is not covered by automated or at least manual tests. One of the most important tenets of the book is that you write code for other programmers (or for yourself), not for the computer. Development speed comes from quickly grasping the intention and implementation when reading, maintaining and changing a bit of code. Refactoring is the process that improves the readability of code. Machines go faster no matter how you write the code, as long as it works.

The book is first describing and advocating refactoring, then presenting the various refactoring moves, in a sort of structured way, akin to the software patterns that Martin Fowler also attempted to catalog, then having a few chapter written by the other authors, with their own view of things. It can be used as a reference, I guess, even if Fowler's site does a better job at that. Also, it is an interesting read, even if, overall, it felt to me like a rehearsal of my own ideas on the subject. Many of the refactorings in the catalog are now automated in IDEs, but the more complex ones have not only the mechanics explained, but the reasons for why they should be used and where. That structured way of describing them might feel like repeating the obvious, but I bet if asked you couldn't come up with a conscious description of the place a specific refactoring should be used. Also, while reading those specific bits, I kept fantasizing about an automated tool that could suggest refactorings, maybe using FxCop or something like that.

Things I've marked down from the book, in the order I wrote them down in:

• Refactoring versus Optimization - Optimizing the performance or improving some functionality should not be mixed up with the refactoring of code, which aims to improve readability of code while preserving the initial functionality. Mixing them up is pitting the two essential stages of development one against the other.
• Methods should use their data of their own object - one of the telltales of need to refactor is when methods from an object use data from another object. It smells like the method should be moved in the responsibility of that other object.
• When it is easy to refactor, choose a simple design - Of course the opposite is true, as well: when you know it will be hard to refactor a piece of code, try to design it first. If not, it is better to not add unnecessary complexity. This is in line with the KISS concept.
• Split your application into self encapsulated parts - One of the ways to simplify refactoring is to separate your application into bits that you can manage separately. If you didn't design your application like that, try to first split it, then refactor.
• Whenever you need to write a comment, consider extracting a method with a meaningful name - or renaming methods to be more expressive.
• Consider polymorphism when seeing a switch statement - Now that is an interesting topic in itself. Why would polymorphism help here? How could it be simpler to understand than a switch/case statement? The idea behind this is that if you have a switch somewhere, you might have it somewhere else as well. Instead of taking decisions inside each method, it is better to split that behaviour in separate classes, each describing the particular value that the switch would have operated on.
• Test before refactoring - this would have been drilled in your head already, but if not, the book will do that to you. In order to not add faults to the program with the refactoring, make sure you have tests for the existing functionality, tests that should pass after the refactoring process, as well.
• The Quantity pattern - Review the Quantity pattern in order to improve readability and encapsulate simple common actions performed on specific types of units.
• Split conditionals into methods - in other words try to simplify your conditional blocks to if conditionMethod() then ifMethod() else elseMethod(). It might seem a sure way to get to a fragmented code base, with small methods everywhere, but the idea is sound. A condition, after all, is an intention. Encapsulate it into a well named method and it will be very clear what the programmer intended. Maybe the same method will be used in other places as well, and then, using polymorphism, one can get rid of the conditional altogether.
• Use Null objects - an interesting concept that I haven't even considered before. It is easy to recognize the need for a Null object when there are a lot of checks for null. if x==null then something() else x.somethingElse() would be turned into a simple x.something() if instead of null, x would be an object that represents empty, but still has attached behavior. An interesting side effect of this is that often the Null object can be made an immutable singleton.
• Code inside Assertions always executes - This is a gotcha I found interesting. Imagine the following code: Assert.IsTrue(SomeCondition()) Even if the Assert object is designed to not execute anything in Release mode, only compiled in Debug, the method SomeCondition() will execute all the time. One option is to use an extra condition: Assert.IsTrue(Assert.On&&SomeCondition()) or, in C#, try to send an expression: Assert.IsTrue(()=>SomeCondition())
• Careful when replacing method parameters with parameter object in parallel processing scenarios - Which nowadays means always. Anyways, the idea is that old libraries designed for parallel processing used large value parameter lists. One might be inclined to Introduce Parameter Object, but that introduces a reference object that might lead to locking issues. Just another gotcha.
• Separate Modifier from Query - This is a useful convention to remember. A method should either get some information (query) or change some data (modifier), not both. It makes the intention clear.

That's about it. I have wet dreams of cleaning up the code base I am working on right now, maybe in a pair programming way (also a suggestion in the book and a situation when pair programming really seems a great opportunity), but I don't have the time. Maybe this summary of the book will inspire others who have it.

Read More

Rites of Passage by William Golding

This is the second book by William Golding that I am reading. Unbeknownst to me, it is part of a trilogy! Even Nobel prize winners for Literature seem to can't help but write the damn things. How is one to finish reading all they want to read?! Anyway, the guy wrote Lord of the Flies, reason for the Nobel and a story I enjoyed both as book and movie. Rites of Passage has many similarities with that book. It happens at sea, on a ship, not on an island, but just as removed from the normal rules of civilised society. It reveals dark depths of human morality. It exposes hypocrisy and narrow mindedness. Golding also won an award for it, the Booker prize this time.

So, what is it about? There is this nobleman, godson of an unidentified but very important man, travelling on a ship from England to "the Antipodes" where he is to take an important state office. The guy is the highest socially elevated person on the ship, giving him some sort of equal footing with the captain himself, who is normally king and church on his ship. Now, the book appears as the journal of said guy, of the name of Talbot, written to his godfather, as a means to thank and humour the man, restricted in his own life by the gout disease. That is where the book is at its most difficult: the language is that of an Englishman noble from the 19^th century, with antiquated words and funny ways of turning them into sentences. I pride myself on having understood and finished it, but now, that I know it is part of a trilogy, I am a bit disconcerted.

Anyway, the journal of Talbot presents us with the marvellous world of a ship at sea, forcing the reader to both empathise with the man, but also share some of his opinions of the lower castes and of the social system. We get to share his view of the current events as well. He thinks of himself as noble, intellectually and morally superior to other people on the ship, while exercising a benevolent and understanding indulgence at the actions of others. He truly seems to be the most intellectual person on board, as educated in comparison with others as a college graduate is to a four grade drop out. However, he is a bit of a dick, full of condescension and of the weaknesses of all men.

The main moral of the story is that his arrogant views on the world of the ship are reasonable, if taking as true the presuppositions he makes as member of his social class and having his position on the ship. However, they are completely wrong as related to what really happened. We understand this in the second half of the book, where he relates the contents of another man's journal, who's perspectives on the situations turn our perceptions on their head. Also, the finale is quite grotesque, revealing that his blindness to the world around him is, more or less, voluntary and part of the social system he represents.

This is a difficult book to read, but one that opens eyes, so to speak. Not only we get to see how English was meant to be used (bah, Americans! :) ) but also the author is taking us through the recesses of the human mind and society and the experience of the read is a visceral and personal one. If you can handle the language and the slow pace, I recommend reading this book.

There is also a quicker option for the ones who want to see what happens without having to read the books. The To the Ends of the Earth trilogy has been adapted to a miniseries, by the BBC, of course, starring Benedict Cumberbatch.

Read More

Hanzel und Gretyl - Number 1 In Deutschland

It's been a long time since I've posted a music entry. Here is one from Hanzel und Gretyl, an Industrial Rock band with Nazi overtones singing mostly in German. Actually, I couldn't say what ideology they have, since the band contains two people from New York who are not even German! But I like their music, this one in particular (I've listened to it on repeat for a day or so). Enjoy!

Read More