pswenson

you use one of the many alternatives

what?

jetbrains.com (intellij, appcode, pycharm,webstorm, rubymine etc)

sublime text atom vim emacs eclipse

sadly and inexplicably, youtube still uses flash for video on the desktop...

Tough situation.

If you want to stand up for yourself you could go over your boss's head. Risky, could get you fired immediately, but could get your boss fired/disciplined and save your position.

You could consult with a lawyer for advice...

The safest thing to do is go with the flow and quit (finding a new job first if possible). But just because something is safe doesn't mean it's the right way to go...

Century Link has 1 Gigabit available in Denver now, but it's $150/mo :(

Everyone needs at least two choices..

alternative?

read up here... https://www.elastic.co/blog/resiliency-elasticsearch/

they had a major data corruption bug last year but have taken measures to correct it. I asked if elasticsearch could be a source of truth at elasticon and they didn't say yes, but they indicated that you "could do it" and it is a goal

how is this a useful comment?

java's impl of lambdas is much uglier and feels hackier than kotlin. java forces everything into a stream + checked exceptions are problematic.

also java 8 doesn't have eatures like string interpolation, default params, etc.

yawn..

Maybe around 2020 we'll get some useful stuff like string interpolation, long strings, default param values, and multiple return values!

I assume you meant statically typed, rather than strongly typed.

Swift has this: var airports: [String: String] = ["TYO": "Tokyo", "DUB": "Dublin"]

Wow, this is the definition of nanny-state. This rule should be removed, not tightened!

What's next? I don't make enough to trade stocks? To gamble? To spend above my means?

you mind sharing your chef recipes? did you use chef to automate jenkins too? there are too few good chef examples on the web....

"Redesign your code so it only interacts with such code at the edges."

yeah, and what if you don't have time to do this? sometimes mocks are appropriate because of schedules and other priorities. Much better to mock than to not write tests because mocking is not pure.

Good points... but what happens when you walk into a legacy code base with few tests that wasn't designed to be tested and is tightly coupled to a component such as a database?

I've found OSGi to be an absolute nightmare. Classloader hacks is not the way to solve Java's dependency problem, it needs to be baked in the language IMO.

I think it's one of those ideas that sounds great in theory, but in reality it all falls apart.

Even if it worked as advertised, fact is many 3rd party libraries have all sorts of issues with OSGi. For example, my company is stuck on Jersey 1.x because 2.x doesn't work properly with OSGi.

Testing is much slower and harder to write. Testing seems to be an afterthought....

I think you can get most of the benefits of OSGi simply by using proper dependency management (Gradle). Use the Single Responsibility Principle and IoC and you'll get good modular code. These are much easer to do, have low risk, and are easy to test.

JMO

I think you are falling into the trap of thinking you can usually recover from an exception. Exceptions are usually caused by one of two things:

1) system error (no more DB connections, hard drive full, etc)

2) a bug

neither of these are recoverable, you just need to stop the task at hand and notify someone that the situation needs to be fixed. Trying to handle it and recover is usually a fools errand that results in hiding the problem

There are cases that you do want to handle exceptions. In these cases, yes catch the exception and handle it. But these cases are the 10% case, hence the default behavior of making the caller handle the exception isn't desirable.

This link from 2003 articulates the point better than I can: http://www.artima.com/intv/handcuffs.html

1) try introducing a Checked Exception in a commonly used method. Soon you'll be updating 100s or 1000s or methods.

2) checked exceptions don't play well with interfaces (APIs) for similar reasons. any interface user must change their code simply because some new checked exception bubbles up now

3) checked exceptions lead to terrible error handling and hiding bugs/system problems. instead of letting exceptions bubble up - java coders almost always write code that either swallows or simply logs the exception and continues along as if nothing happened. If my bank deposit fails, I don't want the failure to just end up in a log file - I want to know it! Exceptions were designed to usually bubble up and be exposed/handled in a standard way at the top level thread. They are usually not recoverable.

4) they lead to bugs. I very rarely see anyone handle the statement/resultset handling of JDBC code correctly.

5) if they are such a good idea, why does no other language ever created has them?

hmm I wonder why this got created? http://ant-contrib.sourceforge.net/tasks/tasks/

I wonder if anyone said this about HTML when javascript was introduced?

once a system starts getting complicated you inevitably need code.

two points:

* gradle builds can be completely declarative. you write code only if you need it

* builds also are often used for very specific automation. in ant, you end up having to write custom ant tasks. this is fairly painful compared to just creating new classes, tasks, or scripts directly in gradle.

that's absurd. 1) I can't embed code in XML. 2) Why should I use a format that takes 5x as much space to declare something as a more usable format?

for normal dependency management you shouldn't need to write code. I've never done any android dev, so I can't comment on that. declaring a dependency is literally like this:

dependencies { compile group: 'commons-collections', name: 'commons-collections', version: '3.2' testCompile group: 'junit', name: 'junit', version: '4.+' }

But I am not going to be the great gradle defender :) I have many complaints..... I would have much preferred that Rake became the default build system for java. Sadly that approach never took off....

w/ regards to gradle using groovy.... in gradle I can easily add in variables to my dependencies, I can write conditionals (if System Prop X then include dependency Y).

Basically anything you can do in code, you can do in gradle very easily.

Auto-complete does work in IntelliJ 13 - at least for groovy code type stuff. Nothing for the gradle DSL (that could be implemented of course).

> Java devs do many things manually that a Ruby/Python dev would be horrified at....

Jenkins config - almost every one does this by hand. Jenkins jobs weren't really even designed to be automated (ironic, eh), you have to build a full xml doc for each job rather than say apply a similar change across all jobs (add in a -D param across all jobs for example). I know this is a Jenkins specific issue, but this mentality is very common in java land.

Others: have every dev manually install a database for their environment (Chef/Puppet/Ansible solve this - and what are they written in? Ruby/Python)

No one would ever use java for any scripting type work, the JVM startup time is awful + the file/string libs are far less powerful/usable than ruby/python.

Of course a java dev can learn one of the scripting langs, but they typically don't.

this is just my experience, but note I've seen a lot of shops...

I'd say Gradle is the least awful of the 3 major build systems. Ant degrades into an unmaintainable mess as soon as any complexity enters the system. XML is a horrible scripting language, simple imperative constructs are very awkward (loops/variables/conditionals).

Maven also suffers from XML hell, but at least it has dependency management.

I've used gradle extensively and it is quite difficult to figure out what is going on. Using a debugger would be nice, but it simply doesn't work. Gradle is terribly slow on a big project, the update checks are the main culprit. They should be done automatically in the background to alleviate this pain.

Since gradle is compiled rather than interpreted, calling code in the project being built is difficult and convoluted. For example, if I want to call a DBUtil.cleanDB() method in my java code I can't reference DBUtil in my gradle script as it hasn't been built yet and the Gradle script won't compile. If gradle was interpreted this problem wouldn't exist....

I find the DSL unintuitive and the inability to specify the order of tasks execution is always a sore point.

On the positive, at least it's a language, not XML. I have never understood the java world's obsession with XML and forcing it in directions never intended. This XML obsession has led to java being a major laggard in automation tech. Java devs do many things manually that a Ruby/Python dev would be horrified at....

I'd like to hear thoughts on CheckedExceptions in part 2. IMO, they are a disaster - most projects degrade into all methods having a "throws Exception" clause. But I'm not sure if there is any consensus on how the CheckedException haters like myself work around them. I use Runtime exceptions everywhere, but it's a pain/boilerplate to convert them.

It seems to me that if you are writing a lot of mocks, you are probably retrofitting tests onto an existing code base. If your code is written to be testable you usually can avoid mocks.

That being said, if you are writing a test on an algorithm and the data comes from a database this means you are not just writing a test on the algorithm - you are writing a test on the database with all the cruft that comes along with that. This test can be hundreds of times slower due to the DB dependency.

So mocks do have their place. The test pyramid is the answer - you need units (sometimes with mocks, integration, system).

In my experience most companies are way too integration heavy and very light on the unit side of things. For example for my current project our dev tests take 12 hours to run. This is the result of going too far away from the unit level and being too integration heavy.

There is a balance! Sounds like the rails world the balance is too unit heavy. In the enterprise world I think it's too integration/system heavy.

you don't sync them by hand. ever heard of ruby gems, maven, gradle, npm? these assets are all versioned and available via http.

these assets can be referenced by many other systems, not just your source repo.

>the sanity of access control? only at a directory level, git has it at a repo level.

>Great, so now the code and the assets going with the code, both being used to build the product, are completely out of sync and essentially unsyncable?

no. read up on artifact repositories. you declare the asset version that you depend on in your a build script. the assets are fetched from the artifact repo.

there pros and cons of course...

also, you can sync to a subdirectory in SVN - not git.

1) yeah, although I question the sanity of doing this. 2) is this related to #3? 3) yes, but IMO VCS should be used for source files (mostly). large assets should go in an artifact repo. But you are right - putting giant files in git is a terrible idea, especially if you change them often.

threads don't have to be more difficult. check out actors.

Meteor seems to think threads are the way to go (Fibers)

don't forget poverty in the 1920s is way different than poverty in 2014.

getting the basic needs like shelter, food, water, heat are a lot easier to come by these days (many government services). And many of the poor have TVs (cable even), cell phones, cars, etc.

my point isn't that being poor is no big deal... my point is the rich AND poor both have it better off than they a hundred years ago.

As I (vaguely) recall, PG made a similar point in Hackers and Painters.