HN user
Yes, but this "enterprise" crapware is the transaction system of your bank, and those "few bytes" are your last paycheck. Have some respect for the software that makes the world around you function.
Grew up on a farm in Scandinavia and have witness a few of these up close. The amount of debris they can accumulate is staggering - mostly nails, and corroded clumps of metal (probably from old farming equipment). There was nothing particular about the fields where their food came from, in fact it would be considered very clean, almost ecological. But hundreds of years of harvesting will leave a footprint. Also, in the earlier days when renovation was not set in system they used to bury their trash (what else could they do really).
I don't know, S3 and DynamoDB are both eventual consistent. And keeping in mind the CAP-theorem it makes sense. And I for one love SimpleDB - it's just that, simple. And great for prototyping (really cheap) and small production-loads. Often you just need a place to stick your data, scalability can be achieved to adding a caching layer.
Could you elaborate on which issues you ran into. We are in the process of upgrading to from jdk7 to jdk8 (at-least for the services we see having a long lifespan) and it would be great to hear some real world experience.
Yep, no problems here. 80GB dataset, indexes are around 10GB, one master, two replicas. Lots of reads, all writes are done in bulk during the night (low read throughput). We also use Cassandra and postgresql a lot - there's no silver bullet when it comes to storage systems.
I worked in the air-force as ground-crew servicing F-16 for a year. Every now and then they would exercise gun target-practice by having one jet tow a red "sail" (I think it was called a "taxan"). The towing-line was several hundred feets long, and the towing jet would fly in a large circle. The practice always intrigued me, and seemed very low-tech compared to some of the other stuff in the domain. Don't know if that was what you saw but - they did not fire missiles at the target how ever, and certainly not over populated area. They always flew out over the North-sea.
I'm from Norway and I had the same experience when visiting Berlin last year - having to take out euro-bills from the ATM. Here in Norway I never carry any actual money - I only ever take out money to pay my foreign hair-dresser which cuts my hair for a low rate. I suspect he does not have a credit-card machine so he can avoid some taxes. I even pay for coffey and other cheap stuff with my card. They say we will go completely cash-less by 2020 - can't wait.
Typically you create your class manually and map to-and-from json-strings. In a web-context you'd usually let the container handle the serialization/de-serialization (jax-rs), in other contexts I tend to use Google's GSON-library.
Give him a break, this is how projects - and especially personal projects - develop. You find a cool idea you want to explore on, the end product might be something totally different then what you started with.
They do sell very well here in Norway at least - and is said to behave decent during the winter: http://www.klikk.no/motor/bil/biltester/article896042.ece
Been using http://commons.apache.org/proper/commons-dbutils for the same purpose. Works well when I don't need the slede-hammer a full ORM-framework can be. Will look into JDBI as well next time.
The replication factor is set to 3, meaning that all data is stored on tree separate nodes - in different availability zones. So in practice the writes per sec is 3x.
I've been a java developer for over 10 years (8 professionally). I've worked as a consultant on large government projects, using legacy frameworks like Struts/Tiles and being forced to use older versions of Java. I've worked for tech-startups being able to use new and hot tech. like Cassandra, jdk8, and the play-framework. And in between I've hacked on a ton of personal projects, including tech like gwt, mongodb, android, etc. I've used lots of frameworks like Spring and Hibernate. Although such frameworks often provides abstractions and encourages usage of design patterns, I've never really found my-self getting lost in their layers of abstraction, and I've can't really say I've come across any "AbstractAdapterFactoryProviderBean"-either.
I've also never found my-self working with a code-base I'd considered clean and highly maintainable. When code-bases becomes big and complex, they tend to get messy. It's hard, if not impossible, to maintain a complete view of the entire application at once - and this leads to different approaches at different times, and places in the code. Having multiple developers come and go, with various levels of skills, does not help either. Having some framework dictate the overall structure of the application limits the potential for to much diversity in the code, it also helps new developers get a grasp of the codebase if they have used the framework, or similar frameworks, in the past.
When I design a simple application, the flow is limited, and I don't need the abstractions - so I don't implement them. But when the system grows in complexity, and the concepts and logic starts to overlap, it becomes reasonable to implement abstractions. To layer the application into DAO, service, persistence layer, etc. To group common logic, and make abstract implementations. I could go on. Abstractions are good, but overuse is also not good - of-course, like everything else it's about finding the right balance.
Having used HazelCast extensively, and considering making some of my code Sirius-depentant, I can tell you that it is not more advanced. Sirius is basically just a distributed key-value store w/no partitioning, whereas HazelCast has a lot of abstractions built on top of the simpler principle[1]. In fact, it might be a bit overkill in some situations, and that's one of the reasons I will consider Sirius.
I'd say that depends on what kind of service the provider is offering. Later generation cloud providers might specializing in providing such VMs - Heroku and GAE comes to mind. But on providers that offer more "bare metal" VMs one should not expect such migration. Indeed it would be almost impossible to do, since it would require a lot of information about the application you are running. Heroku and GAE solves this by limiting the capabilities of the VMs so that they have more control/information about the running applications.
Started with Visual Basic back in 98, switched to java around 2003 and haven't looked back. I can still remember I thought the "Obejct" in "Object Related Programming" was referring to the nice GUI-components in the Visual Studio editor.
When the cloud was first being introduced one of the core principles was that your instances should be considered ephemeral - and that they can terminate at any time, without any notice or further explanation. I think some people sometimes forgets that this still holds today.
Don't expect your instance to run forever. Design your architecture with this in mind. There is a reason e.g. aws provides multiple availability zones.
These guidelines does not apply to all websites but (and I translate) "private and government enterprises, communities and organizations that uses the web as it's main channel for distribution of information to the public". But I'd tend to agree that it's a bit far fetched to force on any kind of guidelines. That's how things play out sometimes - reminds me of how contractors here are forced to build all new houses with certain dimensions on bathrooms, halls, and kitchen to accommodate handicapped people. This again have led to higher prices of housing.
..which is exactly why we have scala, groovy, etc!
One great thing about these new language features is that you don't have to use them. You can run on jdk8 and program as if it was your grandmas vm. This was true for generics and will be true for lambdas etc. As programmers become more advanced they understand the need for the more advanced features and start to adopt them - but they are not strictly required from the start.
I really respect Coda Hale for the work he has done on Dropwizard, and shares his views on Java vs. scala.
As for the java-hate - in my 10 years of java-programming it has always been there. They used to complain about it not being portable enough, not performant enough, GC-pauses, start-up times, and lately that it's to verbose and non-functional. But java has persisted, and only improved over the years. I'm happy I've been able to (mainly) program in the same language for so many years. It makes me realize just how long it takes to truly master a programming language (or perhaps programming in general). I guess that's why they say "..it takes 2 weeks to learn a programming language, and 10 years to master it". It's an art, and the language is your tool.
OVH got a pretty good write-up on their blog[1], well worth a read. It looks as if their solution should be able to mitigate layer 3/4 attacks. From the blog: "Our surplus network has a capacity over 2 Tbps. We have three VAC in production, so we can manage up to 480 Gbps/480 Mpps." Cloud-flare took on the larges DDoS ever seen not to long ago, I think it peaked around 400Gbps.
1) http://www.ovh.com/us/blog/a1171.protection-anti-ddos-servic...
I admit I find my-self thinking from time to time that I need to "return multiple values from this method". But this is not often, and in most cases I find that it is a result of bad design. A method should be short and have a single responsibility, that is at-least the java best practice mantra, having only a single return type help enforce this.
Java devs: what is faster, hashmap or hashtable?
Ok, as a Java-dev I'll bite: They are not really comparable - because their use depends on the situation. One is meant for concurrent access by multiple threads - and thus synchronizes the access, while the other one is not thread safe and should not be used where this is a requirement. If you want the best of both, use ConcurrentHashMap.
There is a concept of a shared resource, e.g. a cache of computed values. A shared resource will necessarily be subject to concurrent modification, and thus requires synchronization. The point is, depending of the situation shared resources may far outweigh the cost of synchronization. These are tools, understand them and use them where they makes sense.
If I understand this correctly then the huge improvement in latency (from 200ms to 3ms) comes from not having to deal with slow clients directly. Traffic to your front-end server are now only from ELB, and ELB is "spoon-feeding" the web-clients. This is true if you are using ELB in "http-mode". This also explains why you can cut the front-end servers by 20% - as each request is handled more efficiently (lower latency equals higher throughput). Also, connection-reuse is more efficient as the set of servers in the ELB-pool is more limited that the set of web-clients.
Not only did he start using revision control - he went ahead and implemented a completely new one!
It's really not that hard to make thing run async / paralell in java: You just create a ExecutorService and submit your runnables / callables. The java.util.concurrent-package makes this easy, and google guava has some useful extensions as well (e.g. ListenableFuture). This approach does of course spawn new threads, but threads are lightweight and using a ExecutorService allows for pooling of the threads (ThreadPoolExecutor). I do this all the time, when I find parts of the code that's worth optimizing - e.g. fetching multiple objects from a distant db-server (like aws).
How common is it to work out of coffee shops? Where I'm from (Norway) I think you'd be asked to leave if you were to be sitting in a coffee shop day in and day out - unless you were drinking a whole lot of coffee, eating a lot of food, and drinking a lot of beer in the evening. Is it mostly a day-time activity perhaps? When the shop could be mostly empty anyway? The start-up culture is not so strong here though, and people tend to lease space in dedicated "start-up spaces".
They should have just incremented on the F-16, now that is an exellent fighter - so elegant and simple. One of the F-16 designers has some great insights on the F-35: http://www.youtube.com/watch?v=UQB4W8C0rZI
Well, it makes perfect sense. You are protecting the client it self - by dictating which sources can be used for fetching information and code. XSS is about malicious code injected on your site, in their browser - it's not the client who's misbehaving.