larsmak

Landing a job in the tech industry in norway is no problem - especially if you are a software developer, IT-consultant, or have any kind of engineering-deegree. Currently there's a huge demand for engineers, esp. in the larger cities. Not knowing the language is not a problem at all, english is well understood and spoken. Source: Working in a multicultural software company in Oslo.

About a year ago I implemented a sub-system relying heavily on MongoDB. The load is not that immense, a couple of hundred requests per minute. The dataset is large however, several hundred GB, spread over millions of documents. Also, updates happens in batch, during the night, while reads are happening all the time. I have not had to touch the system since it was put in production over a year ago - it just runs.

MongoDB is a tool, understand it's strengths and limitations and it will serve you well. We achieves great performance for our use-case by correct schema-design / partitioning of data, and sane use of indexes - which are excellent in MongoDB. If you need to scale large, you need to store the data in such a way that it does not require much resources to fetch them, i.e. you must store the data according to your read-requirements. This is even more true in "key-value" systems like Cassandra, which is more limited in how you can store data. MongoDB is very flexible, so it's a lot easier to shoot yourself in the foot.

I'd be interested in this as well. The workarounds mentioned seems to require a bit to much hacking for my liking. Are there any actual plans for implementing simple disk-usage (and perhaps network) limiting?

Maxmind, http://dev.maxmind.com/geoip/geoip2/geolite2/, is one option. Look into their git-repo for clients to read into their proprietary (but effective) db-format.

> GWT is/was a terrible amount of overhead baggage

GWT is very much alive and kicking, but it's primarily used on internal business applications with large and complex code bases. And what overhead baggage are you talking about? GWT is designed to reduce overhead though cross-compiled, browser-spesific builds, dead-code removal, and js-optimizing.

J2EE-containers can take a while to start indeed (for large projects), but in most cases they can be tuned to restart in less than 10sec - at least during development.

Using GWT you don't "write Javascript in Java", the java-code is written in java and then compiled to optimized, cross-browser, javascript. Compile-times can be quite long - but again, during development you will use the hosted-mode (or even the new super-dev-mode) version, which compiles on the fly. Full java-to-javascript compilation is typically only needed when new versions are deployed to stage/prod.

These stories about mitigating DDoS-attacks often comes up, but there is seldom any actual details on how it was done. I guess it's because there often is a manual process, analyzing logs and banning IPs and/or IP-ranges. But for these more automated mitigating services, what technics are used? I guess some of the techniques are based on complex machine-learning algorithms and considered company secrets. But there must be some general, more well known, automated mitigation techniques / indicators? For application-level attacks is it enough to ban the offending IPs in the firewall? If so, how do one best identify these IPs? Assuming one have access to the access-log, I can come up with a few ideas:

- Like mentioned above; banning IPs / IP-ranges originating from countries normally not associated with traffic to the site (i.e. build a statistical knowledge beforehand)

- Simple request counting, per ip, and IP-ban users who are overly active (again based on the sites statistical profile)

- More advanced request counting, trying to create a fingerprint of the users behaviour (time between requests, etc) - and comparing this to the sites average fingerprint.

- Keep a global request-per-time-count and use this to measure the current load of the site - the mitigation techniques will only be activated if the site is under heavy-load / attack.

Any other ideas?

I tend to agree. The "start-up"-term has become so bloated that it hardly make any sense any more. To churn out hundreds of generic landing-pages based on templates, built with "start-up generators" wont create anything of value.

"Don't have a product - no problem!" Get your idea out there and get that seed-round running - then you can surely hire some eager developer-monkeys to do the implementation.. wrong. IMHO a start-up is a game-changing idea; unique and ahead of it's time. Developing it should take time, and it should be risky - if not it will already have been done.

Well as a person hosting a service under a .io domain I must say that it's next to impossible to find a decent domain under .com these days. They are all taken by domain sharks hoarding away and running link-farms. The .io landscape is a refreshing one, it's well recognized by it's typical audience (tech people), expensive enough so that it's not attractive for the domain-sharks, and there's plenty available.

Why exactly do you hate them?

Hehe, hey, I was gonna say that!

"found they didn't cooperate with tools" ..interesting, care to elaborate?

As many others in here I'm continuously working on start-up ideas when my day-job is over. One of these is nearing it's beta phase. Ideally I'd do a closed beta-test for invite users only. They would have to expect all their data to be lost after the closed beta period. What is the best strategy to attract such users? It's no exactly "Show HN"-material as it's far from a finished product. But I'd like to get early feedback from users that does not expect to much..

The singularity is coming: the day google translate can correctly make that translation.

I think these are all valid points, especially working on something you're passionate about. I would like to add (I guess these apply to general development as well):

- Get into a "serial" mode, i.e. work on a single (small) component at a time, with as few context switches as possible. This can be achived by:

- Breaking your project into small, clearly defined components. This allows you to:

- Pick the component you feel would be fun to work with on this particular day. This should lower the bar for getting started on your project a late sunday morning. If you get stuck or bored, work on some other component.

- Take a walk "All truly great thoughts are conceived while walking" - Nietzsche

"You were not kicked off for taking pictures. You were kicked off for acting odd."

I agree - you can come a long way by just saying "My apologies, I dit not know that", give a short smile and look another way. Inside you might mean something different, and you can silently ponder on what a jerk the opposite person is.. but you need to let the opposite person feel that he/she is in control - especially it it's their job to stay in control.

I agree, some people tend to think that Heroku is some kind of silver bullet that magically scales anything into the sky. But the underlying platform is nothing we haven not used before, and scaling linearly as the userbase grows is no easy task indeed. Give them some slack..

I partially agree. Norway is a pretty small country - and folks here, it's seems, would rather sit on cafés drinking coffy and "solving the problems of the world" rather than getting into the hard world of entrepreneurship. There's just not that many good ideas to fund here (?) There's some gov. initiative, and now they are also open sourcing more (of our) data (and even throws in a competition: www.apps4norge.no)

Also IMHO, Scandinavians needs to stop blaming the "law of Jante" all the time - maybe we should take a look at ourself instead? :)

I'm a sports-climber my-self (around 5'10" and average I guess). What people forget is that as length increases in two dimensions, weight increases in three. Also the top climbers tends to be sub 5'10", but idk, it's all about having fun and compete against yourself!

I started out with Visual Basic about 10 years ago, as an introduction to programming it did it's job well. I then moved on to C/C++ as I started my MSCS. It was great for doing implementation of algorithms and image processing. Working relatively low level, optimizing for speed and handling garbage collection yourself.

As I started my professional carrer I went on to Java, and I've never looked back. The environment is great - I know how to implement algoritms and persistence-framework myself, but that's not what I'm getting paid for. There's always some high quality open source library/framework I can use. And sometimes when I need the "unreasonable effetiveness of C" I will interface with one of it's applications via JNI, I've done this several times: ImageMagick, ffmpeg, OpenCV, etc. I also onload a lot of the performance critical tasks to systems written in C/C++ like MongoDB, Redis etc. But Java can be fast as well, just ask Cassandra and Solr/Lucene.

Java allows me to get my job done, quickly and effectly. And to write well structured, understandable code that most likely will be understandable in decades to come.

Also, write lots of code! If you're stuck with legacy-code, start a hobby project that you think might be useful to someone (if you're not stuck with family that is, then there's really no hope).

I had to stop and think about that one myself. But it makes sence, at least if you emphasize on "hint at". When you wander though the source code, cascading the layers of abstraction, and jumping from place to place, it's nice that the code is somewhat bound to the same context.. in a way. It could be naming conventions, and using the same names for the same things consistently throughout the code. Another way to hint at the overall design is strict structure, e.g. layers: DAO-layer handles persistence, Business-layer handles business, Service-layer handles the interfaces to other parts of the application / other applications, etc. Naming the code-artifacts accordingly hints strongly at what it's doing.

Also code that is not directly dependant on the context (business domain) should be put in a special place, in Java that would be in util-methods "hidden" away in some common-package. This way it does not clutter the rest of the code, and allows for easier reuse.

Well put sir!

6. Some users have developed som kind of "Ad Blindness". I can't remember having seen an Ad in years. Maybe the unconscious mind sees them though (?) That being said, I'm all for advertisements. Content providers have the right to get a ROI for the time they spent producing the content - naturally.

Yeah, I can relate as well. Spending countless, restless hours building small lego-cities. I have no doubt in my mind that that's what got me into an engineering-career. Except now I'm spending countless hours designing complex, high availablity, high scalability, backend systems..

I'm against commenting code, with two exceptions:

- You're implementing something complex (like an algorithm)

- You're implementing something stupid (typically a workaround for something that could not be done in a more elegant way, and you want to explain why it can't be refactored)

If the code is well written it is also self explanatory. This can be done by structuring / formatting the code well, into methods, classes, packages - and naming these constructs in a reasonable way. Naming variables is obviously also very important - and be consistent!

In my opinion comments only clutters the code, and in most cases reduces readability. Like mentioned before you cannot always trust that the comments are up-to-date, but the code certainly will - so I believe time should be spent making the code readable instead. "Look, there is what you intend and what you write" - those should be the same, there should be no in-between.

My primary language is Java by the way (about 10 years of experience).