Perl 6 - the future is here, just unevenly distributed

IRC log for #crimsonfu, 2016-04-10

crimsonfu - sysadmins who code

| Channels | #crimsonfu index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
01:47 ilbot3 joined #crimsonfu
01:47 Topic for #crimsonfu is now http://crimsonfu.github.com - ConfiguRatIon Management of Systems Or Network kung FU | logs at http://irclog.perlgeek.de/crimsonfu/today
12:32 hydrajump anyone using gitlab.com instead of github.com? Just had a look now and it looks really nice. Public/private repos free.
12:33 pdurbin it seems to be gaining popularity
13:58 Azgarech joined #crimsonfu
14:44 Azgarech joined #crimsonfu
16:32 bene i am using gitlab, both personally and at work
16:32 bene free private repos is a win for personal use
16:33 bene and we self-host at work with accounts tied to AD
16:33 bene it's slick and easy
16:51 hydrajump bene: yeah it sure does look nice. Did you previously use github.com for your personal stuff? If so how was the transition?
17:10 bene i had some personal repos on github before
17:10 bene transition was easy, since you're just adding a new remote to the local git repo and pushing to gitlab
17:11 bene i work with a bunch of moderate security paranoiacs
17:12 bene and hanging out with them long enough prodded me to move my dotfiles, personal ansible stuff, etc, to a private repo instead of sharing it on github
17:19 pdurbin bene: did you bother migrating issues?
17:22 hydrajump lol "moderate security paranoiacs"
17:24 hydrajump bene: if you want to contribute to an OSS project that's hosted on github, you'd still have to fork it etc to your own github account, right? You wouldn't fork it to gitlab and than create a pull request there. It has to be done on the same platform as the project?
17:52 Azgarech joined #crimsonfu
17:53 pdurbin hydrajump: if someone fixed some bugs in a branch on gitlab it wouldn't be tough for me to test them out and merge them into a repo on github. It's not a big deal not having it be a pull request. Just tell me where the branch is.
18:01 bene for the occasional pull requests i make, i have just forked to my github account and submitted from there
18:03 bene pdurbin: no one opens issues on my personal repos :-)
18:22 pdurbin :)
19:02 pdurbin bene: right, if I'm *making* a pull request, I would just do it all on GitHub to make it easier on the maintainer. I guess that's what hydrajump was really getting at.
20:32 hydrajump yeah pdurbin. I guess the same is true if you want to open source a project and want contributors having it on gitlab might not yield as much collaboration as if the project is hosted on github
20:38 bear so many things biased in that write-everything-in-java article - I'm not definding Python here (tho, it is my preferred language) but a lot of the points they raised about why java is good is biased to the type of code I'm inferring they write - frontend centric code or small tools
21:08 pdurbin hydrajump: yeah, if you want collaborators github is a good choice right now
21:09 pdurbin bear: yeah. I just thought is was interesting. For those who haven't seen it: http://or8.net/pipermail/codecraft/2016-April/000147.html
21:10 bear it was very interesting, after I read it I just kept thinking "young coder" and then re-read it to make sure I wasn't just being a cranky old coder :)
21:10 pdurbin bear: do you feel like Python scales up to a team of any size?
21:11 bear yes, like all projects it requires work for dependency and tool management
21:11 bear i've seen java projects that are nightmares just as much as python or javascript or ruby
21:12 bear so it becomes more about the people and the process than the language as you scale teams
21:12 bear (or projects)
21:12 pdurbin In theory, Go is supposed to scale up to very large teams.
21:13 bear Go and Rust i've got my eye on for that very reason
21:13 bear but i'm worried that go dependency management will go the way ruby or javascript has
21:15 pdurbin Yeah, I saw a post recently about dependency management troubles in Go.
21:38 pdurbin bear: maybe I'm thinking of this opinion of OpenStack's scaling issues: http://irclog.perlgeek.de/crimsonfu/2014-09-17#i_9370384
21:39 pdurbin "OpenStack's scaling issues from the software engineering perspective"
21:44 pdurbin hmm, but I just skimmed http://lists.openstack.org/pipermail/openstack-dev/2014-September/044872.html again and I don't see anything language specific
21:46 bear yea, those issues are all process and people (managers mostly, as they are the ones who can make or break a young dev team) -- the code base, in any language, is a supporting contributor but not the prime factor IMO
21:50 pdurbin yeah, makes sense
21:51 pdurbin OpenStack is the largest Python project I can think of and if it's scaling ok to big teams, great.
21:53 bear yea, large projects have communication issues more than they have tech issues
21:53 bear now, having some bad tech and/or code can drive a team to the cliff soooo much faster, but eventually all large teams will reach the cliff
21:53 pdurbin heh. the cliff
21:54 bear what happens when you reach the cliff is all about how you built the team
21:54 bear if they are dynamic and happy and engaged, they will build a bridge and everyone will cross safely
21:55 bear if they are burned out and cranky, then they will jump off of the bus (your project/company) and drink heavily as the bus goes over the cliff
21:57 bear to continue my analogy - you have two choices when approaching the cliff: slow down or start planning the bridge
21:58 pdurbin the cliff is crippling technical debt?
21:58 pdurbin debt you could handle for a while but that overtakes you?
21:59 bear yea, the cliff can be any of a couple of items
21:59 bear tech debt that prevents you from doing something new or keeping something old running
21:59 bear heck, as I was coming up with others I realized that the vast majority of the items all revolve around tech debt
22:00 bear because your either dieing because of tech debt failures or your team doesn't have the mental energy to do new things
22:01 pdurbin planning the bridge sounds good
22:02 bear it's hard to do because you have to get buy in from the management that some things just won't get done with the old system
22:02 bear and that the velocity will slow down before things ramp up
22:05 pdurbin bear: that reminds me of this post: Framing it wrong: management won't let us refactor +Martin Fowler said, "This… - https://plus.google.com/+PhilipDurbin/posts/DV7azLuFUc4
22:06 bear yea, that is the biggest thing new tech managers get wrong, framing the conversation to be about the code and not about the business
22:06 bear the code exists only to make the business smarter, faster, better -- devs tend to forget that
22:09 pdurbin yeah
22:10 bear now because devs are one of the larger cost units... you have to frame the increase in feature or bug-fix velocity as a cost-of-goods model
22:11 bear refactoring "this" will allow the team to have less bug-fix time and more feature time so our feature delivery rate will be positive
22:11 bear but to do that you have to measure velocity - an oh my do devs hate being measured
22:12 pdurbin we'll find out if there really are 10x developers :)
22:14 Azgarech joined #crimsonfu
22:16 bear yep
22:17 bear I always try to let people know they are on a team not because of their coding or bug fixing speed but how good they are at being on a team
22:17 bear now they can't be extremely bad..., but few devs are really bad
22:19 pdurbin bear: are you a fan of the "two pizza team" idea?
22:20 bear not as an absolute but as a method to break up tasks into manageable chunks
22:21 pdurbin or maybe responsibility for ongoing maintenance and evolution of a subsystem
22:22 pdurbin subsystem, service, microservice, etc
22:29 bear right
22:30 bear (sorry, i was being distracted by some of the fud and bias and elite comments being tossed around hangops channel, that's what I get for "reading the comments")
22:31 pdurbin :)
22:32 pdurbin huh. I'm not seeing any message over the last few days at https://botbot.me/freenode/hangops/
22:32 bear the reason for the pizza sized teams is to enable knowledge transfer - both for mentorship and systems
22:32 bear sorry - the slack channel
22:32 pdurbin oh
22:33 bear during the week quite a few in-the-trenches ops folk are online - but over the weekend it tends to devolve
22:34 pdurbin ah
22:35 bear but yes, pizza sized teams make it easier to keep track of and also intervene when things go sideways
22:36 bear but I also want to ensure that people can migrate from team to team - otherwise you get task burnout
22:36 pdurbin makes sense
22:36 pdurbin So do Go and Rust scale beyond pizza sized teams? I guess that's the idea.
22:36 bear that is what i'm waiting to hear about
22:36 bear I know some large teams have focused on both, but only for the last year
22:37 bear so I need to wait for them to get some tech legacy/debt in those languages and *then* we will see how they scale
22:37 pdurbin I haven't actually hear this about Rust, but I'll take your word for it.
22:37 pdurbin bear: how large are these teams?
22:37 bear rust is turing out to be very modular and *extremely* fast for dev refactoring
22:38 bear I know of a couple go teams that are in the 20+ range, a handful that are in the 10-12 range
22:38 bear almost all of the rust teams are sub-teams of larger teams
22:39 bear my sense is that rust is going to be the breakout language at some of the [dev]ops conferences this year
22:39 pdurbin interesting
22:39 bear (if that does happen then I know I was measuring the right spots, if not then I need to get some new contacts ... :) )
22:39 bear because right now it's all about nodejs and go
22:40 bear well, and scala, clojure and python
22:40 pdurbin somehow I thought devops folks were still using Perl and Python and Ruby
22:40 bear (in order of how legacy it is) -- perl, ruby, python, go
22:41 bear those using perl and ruby don't realize they are using it (think cfg mgmt tools or devops tools)
22:42 bear a lot of ruby/python folks are switching to go because of co-routines and being able to do threading without shooting yourself in the foot
22:43 pdurbin meanwhile: [codecraft] Google may be considering Swift for use on Android - http://or8.net/pipermail/codecraft/2016-April/000144.html
22:44 bear I wonder how much of that is being driven by the patent/lawsuits they just lost
22:50 pdurbin hard to say. could be
22:52 bear if anything that was probably one of many items that made them say "yes" to the team that wanted to try it out
22:52 bear the other being that Swift is now cross platform and open source
22:52 bear makes me wonder if microsoft is going to do the same with Mono or F#
22:54 pdurbin I thought F# was already open source. And .Net these days.
22:56 chasmo77 joined #crimsonfu
22:56 bear it is, but without the IDE and supporting frameworks also being open source, it was hard to really use on other non-windows platforms
22:57 bear and that is what the mono folks were doing, building up the tooling
22:57 bear but now it's all under the Microsoft umbrella with the level of support that would make me consider seriously using it for production
22:57 bear sorry - not Mono per se, but rather the folks behind mono - symbian I think?
23:00 pdurbin ah. the people ok
23:00 pdurbin perhaps a bit like how CentOS got brought into the Red Hat Inc. fold. It makes CentOS more trusted, perhaps.
23:01 bear about 15 years ago I toyed with the idea of using Delphi for cross platform because they had moved to the .net framework - but the support libs for each platform was just not supported
23:01 bear yea, trust may not be the right nuance, but it gets to the heart of the matter
23:06 pdurbin wow, Delphi
23:13 bear :) - that was my goto language for most of the late 90's and early 2k's
23:18 hydrajump i thought I saw something about mono on twitter earlier today
23:18 pdurbin :)
23:19 hydrajump https://twitter.com/migueldeicaza/status/715579598667276289
23:20 hydrajump open source

| Channels | #crimsonfu index | Today | | Search | Google Search | Plain-Text | summary

crimsonfu - sysadmins who code