joshdev's comments

I wonder if it makes sense to create a new uri scheme for local https access. Something along the lines of locals://<ip>, which would receive different treatment by browsers.

* Mythical Man Month

* Pragmatic Programmer

* Code Complete

I think the main issue is that beyond the very basic examples the new Docker 1.12 swarm features aren't really production ready. At this point there is a significant amount of tooling required to get a production cluster running with your applications. The Distributed Application Bundles (DAB) files, one of the features I was most excited about, are still marked as experimental.

Overall I think Docker is heading in the right direction, but for now Kubernetes, ECS, etc... are better solutions for orchestration. I was hoping to only use Docker for my current project, but I think I'll have to wait until the next one rolls around and Docker releases a few more updates.

Based on my experience with SaaS, those that do offer Open Source software, are only open sourcing the core of their product. There is typically a whole suite of tools and add ons that expand their core offering into something that makes it more beneficial for companies to just go with the SaaS offering. Deployment and monitoring are two pieces that come to mind.

It appears to be a fork of Atom.io. Just take a look at the app contents on OSX.

  $ ls "Visual Studio Code.app/Contents/MacOS/"
  Atom

That's where I think containers come in handy. Assuming you have other services you are managing you can pack them into instances running your main workload. https://aws.amazon.com/blogs/aws/cloud-container-management/ will likely make that very easy to manage, assuming you are willing to go all in with Amazon.

I agree that there is value in having a team handle both the research & development phases. That said, you may not need the full team to handle research. Not all team members may be interested in research related tasks or have the discipline to execute effectively on them.

From a company standpoint the challenge is to make the research phase valuable, even when the results are not positive. With limited resources, it is tough to balance too much or too little research. As the phase is harder to plan for, you are usually stuck with some timeboxed effort. There is immense pressure for that timeboxed effort to provide some direction for moving forward.

OSSEC combined with Logstash, Elasticsearch, and Kibana can give you a lot of this data on the fly. Here is my list of bad ssh logins from the past 24 hours.

  Taiwan              145963   
  China               15881  
  Korea, Republic of  14079  
  United States       9600   
  Kuwait              1769   
  Thailand            1563   
  Portugal            1518   
  United Kingdom      788  
  India               558  
  Saudi Arabia        284  
  Russian Federation  190  
  Japan               146  
  Turkey              94   
  Bulgaria            83   
  Brazil              35   
  Netherlands         33   
  Rwanda              28   
  Hong Kong           22   
  Germany             19   
  Romania             15   

Some details on the end to end setup https://groups.google.com/forum/#!searchin/ossec-list/kibana...

Some more context here would be useful. It's easy to assume the request is 100% ridiculous from the PM's side, but maybe the project has seen a significant decrease in quality recently. Has the bug rate skyrocketed? Have outages been on the rise? I'd expect a senior level person to be able to identify the warts and put a plan together on how to raise quality as a whole on the project. Educate them on what the right question to ask is, How can we improve quality, and have a well thought answer to follow it up with.

Light on details, mainly a marketing blog post for paid DDoS services, move along.

Buying more RAM only gets you so far. G1 handles large heaps fairly well, but you can still run into issues with long pauses if you are not careful and those pauses increase with the size of the heap. Most real time services don't have the luxury of manually triggering GCs and must do whatever they can to limit the stress they put on the collector.

+1 for Trove. Recently when working with collections with 10s of thousands of primitive elements. We saw substantial memory savings by using Trove.

http://en.m.wikipedia.org/wiki/Second-system_effect not much has changed in the past 40 years

At my company we started a Scala project a little over a year ago. Two of us had a Java background the other two had a C++ background. We targeted Scala 2.9, Akka 1.3, and ran it on JVM 1.6. For us the stack proved to be very easy to work with. The project spent about 5 months in development and has been in production for another 9 months with weekly updates.

What the author calls old habits, I call productivity. A lot of us started off coding imperatively and slowly started adapting functional along the way. It allowed us to get the best of both worlds. Over the past year we've definitely stumbled a few times (mutable objects for akka messages are really really bad), but overall we've been very happy with the stack.

One of the only real ongoing problems we are continuing to struggle with is limiting the impact of big GCs in production. Scala tends to generate more garbage then pure Java, so the GC has to work harder. Most of these objects are in the eden space, but we can run into memory fragmentation issues, which leads to eventual long compaction cycles.

It's really not a bad way to go. You may still get reactions like you've come to expect from developers, but a sign of a good developer is whether after having that knee jerk reaction, they start asking about your technology choices and how you've implemented things. Essentially you want a generalist who is technology agnostic and is willing to roll up their sleeves and get to work in any codebase. PHP isn't that different from other languages and after a week spent learning the nuances with a little training help they should be able to be productive.

It's all in how you approach programming. If you view it as a puzzle and enjoy finding new ways to optimize some workflow it can be very enjoyable. Yes there are tedious moments, but those goes with just about any career out there and I'd argue that programming has a lot less tediousness compared to other jobs out there.

The question to ask yourself, is if you are finding programming not fun, is this really the career path for you? Don't waste your time doing something you don't enjoy.