HN user

greenonion

466 karma

Software engineer based in Athens, Greece.

twitter: @nikosfertakis

Posts31
Comments22
View on HN
engineering.skroutz.gr 5y ago

How We Classify Products at Skroutz

greenonion
2pts0
engineering.skroutz.gr 5y ago

Uncovering a 24-year-old bug in the Linux Kernel

greenonion
497pts41
engineering.skroutz.gr 9y ago

How we migrated our JavaScript stack to Webpack

greenonion
18pts0
nathanmarz.com 9y ago

Clojure's missing piece

greenonion
10pts1
engineering.skroutz.gr 10y ago

Implementing a fuzzy suggestion mechanism at Skroutz

greenonion
5pts0
www.pandastrike.com 10y ago

HTTP is the new Lisp

greenonion
2pts0
juxt.pro 10y ago

Concerns with ring-clojure

greenonion
4pts0
engineering.skroutz.gr 10y ago

Skroutz Redesign: how we designed and implemented our own Design System

greenonion
2pts0
clojure.org 10y ago

Clojure.spec Guide

greenonion
3pts0
overtone-recipes.github.io 10y ago

Recreating Daft Punk's Da Funk with Overtone and Leipzig

greenonion
375pts98
endlessparentheses.com 10y ago

Running Emacs on Android

greenonion
79pts20
engineering.skroutz.gr 10y ago

Optimizing Continuous Integration at Skroutz

greenonion
2pts0
gigasquidsoftware.com 10y ago

Kolmogorov-Uspensky Machine

greenonion
3pts0
benkampha.us 10y ago

Why AlphaGo Matters

greenonion
3pts2
github.com 10y ago

Git-based issue management

greenonion
6pts2
doc.rix.si 10y ago

Complete Computing Environment

greenonion
3pts0
clojure.org 10y ago

The new Clojure web site is live

greenonion
3pts0
adambard.com 10y ago

Clojure SQL library showdown

greenonion
1pts0
blog.juxt.pro 10y ago

Clojure Data Macros – Expanding abbreviated data literals

greenonion
1pts0
numergent.com 10y ago

ClojureScript performance revisited

greenonion
26pts6
engineering.skroutz.gr 10y ago

On prototyping

greenonion
1pts0
medium.com 10y ago

Clojure lazy evaluation and stack overflow exceptions

greenonion
1pts0
www.youtube.com 10y ago

Guy Steele: Growing a Language (1998)

greenonion
17pts0
blog.fogus.me 10y ago

Inspirational technical books that are not technical

greenonion
1pts0
programming-digressions.blogspot.com 10y ago

Best Clojure Books

greenonion
3pts0
justpaste.it 10y ago

Open letter to the mayor of Athens by the founder of its largest coworking space

greenonion
2pts0
www.booleanknot.com 11y ago

Structuring Clojure Web Applications

greenonion
1pts0
github.com 11y ago

A simple Ruby library with String Metric algorithms

greenonion
1pts0
engineering.skroutz.gr 11y ago

Skroutz infrastructure at a glance

greenonion
4pts0
engineering.skroutz.gr 11y ago

CSS at Skroutz

greenonion
3pts0

I think you are oversimplifying the events. I'm not suggesting there was nothing wrong with EAM. However, the article is about the British involvement that lead to the December '44 events. They freed and armed the Greeks who collaborated with the Nazi regime and they disarmed (or tried to disarm) only ELAS members. Of course Greek citizens would protest against that. And it was policemen armed by the British who opened fire against a peaceful crowd. I really can't see how you can justify this.

You assume that all members of EAM/ELAS were communists. They were not. Also, there really was a window for them to take over: after the Nazis left and before the Allied forces arrived they were practically the only armed force in Greece. However they chose to wait.

Mark Mazower's "Inside Hitler's Greece: The Experience of Occupation 1941-44" is an excellent book on the subject.

So since some of the Greek fighters - meaning those who allied with the British against the Nazis, had communist ideals you assume that all they wanted was a violent take over and establishing communism. And based on that assumption you justify the British for (a) arming Nazi collaborators and (b) opening fire against civilians in a peaceful demonstration.

Well done!

While I do not know the specifications of your Elasticsearch cluster, I am really surprised by your experience.

We (at skroutz.gr) use a moderately small cluster (four nodes) and easily process > 4 million rows a day and view them on Kibana dashboards in real-time. We also have success running aggregations on data going back as far as 3 months.

Although I do agree that today's events show that Stallman is right to be that much worried, I have to point out that his argument against face recognition is a weak one. Computer vision is superior to human in many aspects, and this is why the situation we 're facing is very complex.

Thank you for that link, I wasn't aware of that. Even though the reasoning behind their model is mostly logistics it is good to know that every person on Watsi will get his/her treatment regardless of when/if it gets funded.

I believe that information should be on a prominent spot on their website.

Maybe this comment is off-topic here but I can't help but feel that Watsi is in a way making all these individuals "compete" in terms of who is more likable, or whose situation is the worst, in order for them to get the help they need. Maybe I'm exaggerating but this model really troubles me.

Just when I decided I'm only going to be using LTS releases in the future. If they actually go through with this I hope there will be a general update option like choosing between "conservative" and "cutting-edge" updates.

This is great. As a new Django developer one of my most frequent Google queries is "best practices about x in django". I am thrilled to finally have so much of that stuff in one place.

You got me a bit confused here. If I understand correctly what you 're saying, you 're still using Python for prototyping the core algorithms and C++ in actual production systems. I'm not saying Python is not good for production systems in general, I'm wondering whether it is good enough for real-world implementations of machine learning algorithms.

Also, I believe most people would consider Java as an alternative to C++, hence all the Java-based Apache projects, such as Mahout, Solr etc.

So is there anyone using Python for machine learning in production systems (i.e. not just for prototyping). I would love to do it but seems Java/Mahout is a safer choice, performance-wise.

I wonder whether Blaze is a step towards that direction.

Well I guess that makes sense, seeing that version 2 hasn't been updated since 2009. Too bad though, it is really well-written.

I don't necessarily disagree with you. However, I find that most contemporary real-world ML applications (from face recognition to collaborative filtering to computer vision) do use algorithms that "learn from data", using some kind of learning technique, i.e. supervised, unsupervised or a combination of those.

The process of creating that kind of algorithm is also very different: it is based heavily on mathematical/statistical/probabilistic methods and hence the resulting algorithm can be proven that it works with some kind of certainty. On contrary, creating an EA is mostly some kind of "art" (as one UCL professor put it).

All in all, I can't help but feel that even though they are both approaches to the same problem ("how can a computer program learn?"), data-driven methods and EA algorithms don't share much more. And since the results produced by the former are what most people expect of an ML algorithm to accomplish, I tend to think of those when using the phrase "machine learning".

But it's all about semantics in the end.

// I noticed that you are an ML PhD student. So you know exactly what I'm talking about.