Podcast suggestions?

[ranjith]

Javaposse was one my main sources of Java and Techsphere news . I enjoyed the podcast even when there was not real Java news, as there would be some new tech or topic of interest in every episode. 

Given that the podcast now a days is mainly about round up sessions, I am trying to find out similar podcasts that is funny and interesting (tech content - android, java, software etc.)

I still listen to drunk and retired, software engineering radio .

I am wondering if there are any other suggestions.. 

[Michael Burgess]

If you are after an android dev podcast the Android Developers Backstage podcast is worth a listen, you may even recognize a couple of the hosts http://androidbackstage.blogspot.com.au/

[Josh Juneau]

I recommend the Java Pub House podcast...it is very good!  It is recorded by leaders of the Chicago Java Users Group. 

http://www.javapubhouse.com/

Josh Juneau
june...@gmail.com
http://jj-blogger.blogspot.com
https://www.apress.com/index.php/author/author/view/id/1866

--
You received this message because you are subscribed to the Google Groups "Java Posse" group.
To unsubscribe from this group and stop receiving emails from it, send an email to javaposse+...@googlegroups.com.
To post to this group, send email to java...@googlegroups.com.
Visit this group at http://groups.google.com/group/javaposse.
For more options, visit https://groups.google.com/d/optout.

[Mark Derricutt]

On 5 May 2014, at 1:45, Josh Juneau wrote:

> I recommend the Java Pub House podcast...it is very good! It is recorded
> by leaders of the Chicago Java Users Group.
>
> http://www.javapubhouse.com/

The Chariot TechCast is also good for news:

http://techcast.chariotsolutions.com/

[Cédric Beust ♔]

Thanks for the link, I didn't realize Tor and Chet had branched out to their own podcast.

I guess it means that the Javaposse is officially dead(?).

-- 

Cédric

--

[Jan Goyvaerts]

It's a downtime indeed :-(

I'm now more on Linux podcasts: Linux Outlaws, Linux Voice, Full Circle, ... those are funny. And interesting - if you're into Linux.

And the occasional Scalawags with Dick Wall. But that's Scala. And barely comprehensible when Daniel gets too deep into Type Theory. :-p

[drehorgelmann]

IMO it's been dead for quite some time.

I agree with Mark recommending Java Pub House, that's an excellent podcast.

[Mark Mikkelson]

Javaposse was always part of my podcast listening regime, although I usually skipped the poor audio quality roundups so that seems sadly that Javaposse is done for me :(

Anyhow, here are the current ones I listen to regularly whilst commuting: 

- http://dotnetrocks.com (.net however, they talk about a lot more than just .net, upbeat and lighthearted)

- http://hanselminutes.com (only started since http://thisdeveloperslife.com stopped putting out regular content, not this developers life is more interviews and stories than news)

- http://thechangelog.com/podcast/ - Open source news/interviews with the latest open source type stuff

[Linas Jakucionis]

I have been listening to
http://www.illegalargument.com/

This covers a good range of topics but sometimes one of the hosts goes
into too much technicalities of definitions.

[Mark Derricutt]

On 23 Sep 2014, at 22:58, Linas Jakucionis wrote:

> I have been listening to
> http://www.illegalargument.com/
>
> This covers a good range of topics but sometimes one of the hosts goes
> into too much technicalities of definitions.

That just might be me - or maybe Greg. The arguments are strong between
us.

Mark

[Lubos Krnac]

Apart from already mentioned Java Pub House and Chariot Developer News, I am listening to DevNexus podcasts. These are talks recorded on DevNexus conference. So sometimes you feel like blind. But most of the time it's understandable even without slides and if you are interested you can try to find them later. Not pure Java though.

[pwagland]

Which is one of the reasons that I listen. I love the opinionated views that are opined. And I strongly endorse any podcast that doesn't like Maven ;-)

[Mark Derricutt]

On 25 Sep 2014, at 20:45, pwagland wrote:

> Which is one of the reasons that I listen. I love the opinionated
> views that are opined. And I strongly endorse any podcast that doesn't
> like Maven ;-)

Maven is a love/hate relationship - much like iTunes - it's not great,
it's just that it's still better than everything else.

Mark

[Cédric Beust ♔]

My feelings exactly. Every time a new build system comes out, I get excited, I try it and I realize that while it does fix a few things that don't work very well in Maven, Maven still wins overall in usability, productivity, tooling and general support.

And yes, I put gradle firmly in that category. I'm excited about Gradle for a few things but overall, it's still not a very clear jump forward compared to Maven (and I think Android's decision to standardize on Gradle is a mistake that they will back pedal from in the next couple of years).

-- 

Cédric

--
You received this message because you are subscribed to the Google Groups "Java Posse" group.

To unsubscribe from this group and stop receiving emails from it, send an email to javaposse+unsubscribe@googlegroups.com.

[clay]

Wow, I'm surprised that people prefer Maven over Gradle.

I prefer Gradle for a few reasons:

- Way more concise. Gradle has a much cleaner syntax and doesn't require mountains of XML for everything. Each library dependency in a typical Maven pom often uses five lines of XML which is silly. Gradle and SBT have a much leaner syntax. I've converted Maven builds to Gradle and while still using plenty of comments and white space and not intentionally trying to write terse builds, the Gradle build is often an order of magnitude smaller. Like 5-8 times smaller.

- Declarative when you want it, imperative logic when you need it. I've heard people say Maven forces you to be declarative, which is silly. Maven users frequently cram all kinds of file copying steps and other imperative logic into their XML Maven builds. Gradle is just designed to handle this use case well.

- Multi-project builds are handled better. Gradle's approach of allowing everything in two files at the root (build.gradle/settings.gradle) is better than having pom.xml files scattered throughout the tree. Intra-tree dependencies are handled better. Shared third party library dependencies are handled better.

Tooling? Maven is obviously more popular. IntelliJ has excellent Gradle support, but other IDEs may not.

On Sunday, September 28, 2014 9:33:31 PM UTC-5, Cédric Beust ♔ wrote:

My feelings exactly. Every time a new build system comes out, I get excited, I try it and I realize that while it does fix a few things that don't work very well in Maven, Maven still wins overall in usability, productivity, tooling and general support.

And yes, I put gradle firmly in that category. I'm excited about Gradle for a few things but overall, it's still not a very clear jump forward compared to Maven (and I think Android's decision to standardize on Gradle is a mistake that they will back pedal from in the next couple of years).

-- 

Cédric

On Sun, Sep 28, 2014 at 6:18 PM, Mark Derricutt <ma...@talios.com> wrote:

On 25 Sep 2014, at 20:45, pwagland wrote:

Which is one of the reasons that I listen. I love the opinionated views that are opined. And I strongly endorse any podcast that doesn't like Maven ;-)

Maven is a love/hate relationship - much like iTunes - it's not great, it's just that it's still better than everything else.

Mark

--
You received this message because you are subscribed to the Google Groups "Java Posse" group.

To unsubscribe from this group and stop receiving emails from it, send an email to javaposse+...@googlegroups.com.

[Cédric Beust ♔]

All these points were what got me excited about Gradle in the first place but the honeymoon didn't last long (well, actually, it lasted a few years and I'm only now beginning to grow a bit more sour).

I thought that Gradle's conciseness was awesome until I realized that even after years of usage, I still needed to copy/paste snippets from StackOverflow whenever I needed to do something that was not cookie cutter. I was hardly ever able to figure these bits out by myself. I blame (partially) Groovy for that since some code completion would help there, but overall, this is due to the fact that the Gradle syntax is trying to be both declarative and imperative but ends up being neither. So I can't use my IDE to complete code nor to complete declarations.

I also used to think the Maven XML syntax was heinous but I've come around this as well for a few reasons:

1. The XML choices that Maven made are extremely regular (e.g. no attributes ever) which makes writing the XML very straightforward. I never wonder if it's <foo bar="1" /> or <foo><bar>1</bar></foo>.

2. I actually never even write any of this because the Maven XML schema makes writing pom.xml close to trivial in any of the two IDE's I use on a daily basis. It's mostly a matter of control-spacing my way through.

I have a more thoughts but my attention is required elsewhere right now.

-- 

Cédric

[Fabrizio Giudici]

On Mon, 29 Sep 2014 04:33:07 +0200, Cédric Beust ♔ <ced...@beust.com>
wrote:

> My feelings exactly. Every time a new build system comes out, I get
> excited, I try it and I realize that while it does fix a few things that
> don't work very well in Maven, Maven still wins overall in usability,
> productivity, tooling and general support.

Amen.

--
Fabrizio Giudici - Java Architect @ Tidalwave s.a.s.
"We make Java work. Everywhere."
http://tidalwave.it/fabrizio/blog - fabrizio...@tidalwave.it

[Fabrizio Giudici]

On Mon, 29 Sep 2014 04:45:47 +0200, clay <clayt...@gmail.com> wrote:

> - Declarative when you want it, imperative logic when you need it. I've
> heard people say Maven forces you to be declarative, which is silly.

It depends. When you have heterogeneous groups where you have to enforce
some order, declarative is better because you can force people to stick
with a standard way to do things.

> - Multi-project builds are handled better. Gradle's approach of allowing
> everything in two files at the root (build.gradle/settings.gradle) is
> better than having pom.xml files scattered throughout the tree.

Really most of my pom.xml files in modules just contain coordinates and
inherit everything from the master pom. BTW in some projects that I booted
and how I help in maintenance, I constantly find people adding useless
stuff in pom.xml, that should be inherited instead. Usually it can just be
deleted. I can only figure out the mess that they'd do if imperative stuff
was allowed.

It really depends on the kind of team you have.

[Mark Derricutt]

On 29 Sep 2014, at 15:45, clay wrote:

> - Way more concise. Gradle has a much cleaner syntax and doesn't
> require
> mountains of XML for everything. Each library dependency in a typical
> Maven
> pom often uses five lines of XML which is silly. Gradle and SBT have a
> much
> leaner syntax. I've converted Maven builds to Gradle and while still
> using
> plenty of comments and white space and not intentionally trying to
> write
> terse builds, the Gradle build is often an order of magnitude smaller.
> Like
> 5-8 times smaller.

Yes - Gradle may be far more concise, and can be more readable - I find
it's more the ecosystem of plugins, and other tool integration to be
more important. Add to that - ivy ( and derivatives ) are not 100%
compatible with Maven ( i.e. timestamped SNAPSHOTs for a big one ).

One my biggest issues with Maven is now solved since we (Richard Vowles
and myself) took over the grossly broken, unsupported, but
well-intentioned tiles-maven-plugin [1] which gives us mixin style
composition of Maven concerns.

Being able to refactor those common things makes our build files
amazingly small. i.e. I declare a set of tiles for "osgiapi,
codestandards, karaffeature" and everything for our standard
checkstyle/enforcer rules come in, standard setup for an OSGi based API
package gets configured, and support for Apache Karaf etc. These can be
added at will, without horrible nested parents.

Works remarkably well.

[1] https://github.com/repaint-io/maven-tiles

[clay]

On Monday, September 29, 2014 2:30:38 AM UTC-5, fabrizio.giudici wrote:

It depends. When you have heterogeneous groups where you have to enforce  
some order, declarative is better because you can force people to stick  
with a standard way to do things.

Maven gives a very superficial illusion of forcing declarative builds. However, it is common to see imperative logic in Maven builds in the form of ant tasks or plugins. Some builds really do justify imperative script logic, Gradle just supports this with an actual programming language.

If you have a standard build, declarative build definitions are great. Gradle and SBT really don't stop that. In fact, they make simple declarative builds much more concise than Maven's mountains of XML.

Maven is designed with fixed build tasks and a fixed pre-defined lifecycle. Many projects have genuine need for custom build steps. Maven expects you to rig your custom build steps into the predefined steps. Gradle lets you define new tasks and task dependencies as you need them.

[clay]

On Sunday, May 4, 2014 12:29:24 AM UTC-5, ranjith wrote:

I am wondering if there are any other suggestions.. 

Back on the OT: I love scalawags with Dick Wall and others. It seems that Java Posse has been unofficially phased out in favor of these newer podcasts that cater to more specific niches.

[Fabrizio Giudici]

On Tue, 30 Sep 2014 01:39:49 +0200, clay <clayt...@gmail.com> wrote:

> On Monday, September 29, 2014 2:30:38 AM UTC-5, fabrizio.giudici wrote:
>>
>> It depends. When you have heterogeneous groups where you have to enforce
>> some order, declarative is better because you can force people to stick
>> with a standard way to do things.
>>
>
> Maven gives a very superficial illusion of forcing declarative builds.
> However, it is common to see imperative logic in Maven builds in the form
> of ant tasks or plugins. Some builds really do justify imperative script
> logic, Gradle just supports this with an actual programming language.

That's precisely the point for which Gradle is a disaster. I have five
years of experience with Maven now and there's no illusion. Rather I can
say that there's a clear barrier between things that are declarative and
things that are imperative (plugins or occasional ant tasks)...

> Maven is designed with fixed build tasks and a fixed pre-defined
> lifecycle.
> Many projects have genuine need for custom build steps. Maven expects you
> to rig your custom build steps into the predefined steps. Gradle lets you
> define new tasks and task dependencies as you need them.

... which is precisely why Maven is better than Gradle. I cannot count the
projects that I've done with Maven and with the proper assistance they all
fit in the Maven lifecycle. There were just two exceptions: an ant task to
invoke iac for a period of time in which there was a bug in the Maven
plugin and a project that had a long history before being mavenized and
that needed a customization in creating some artifacts for functional
tests. In both cases the ant tasks have been carefully designed by the
expert (me) and placed in the superpom. Nobody had to know that there was
an ant task invoked, nor had the chance of tweak it. In other words, with
a proper design of inheritance you can confine the very few customization
in a place where nobody touches them.
On the contrary, make it easy to write custom scripts and you're soon in a
storm of shit. My customers precisely appreciated that, after the
mavenization, tons of custom scripts (usually made with Ant, in which
everybody had the good idea to incrementally add tweaks) were thrown away.

> If you have a standard build, declarative build definitions are great.
> Gradle and SBT really don't stop that. In fact, they make simple
> declarative builds much more concise than Maven's mountains of XML.

I'm not obsessed by tags and none of my customers are. In the end what one
wants in a project is to reduce costs (time and money) and a few xml tags
don't really make a difference here. Xml obsession is just conference
hype. BTW, with Maven 3 poms could be written in json, so Xml is no more a
constraint, but as far as I know nobody felt the need to do that.