We are using concourse at work right now and have 50-ish pipelines for various repositories. IMO, there's definitely some work you have to put into it because you'll sooner or later run into a problem with the existing resources and need a custom one. Writing custom resources is pretty easy however.
Concourse also isn't really made to work well with the Git Flow, there is no builtin way to run the CI on multiple branches (there's a git-multibranch community resource which requires redis at some point). we're basically thinking about changing our workflow to trunk-based, but it still feels weird to me that we might change our workflow to fit our CI better.
that being said, I personally still really like concourse and it's fun to work with.
You could try contributing to gitlab.com, I didn't know any Ruby when I started contributing but they have an awesome guideline and issue tags that show you what's easy to do for you. You get high quality code reviews and they help you a lot when you struggle.
I work for Volkswagen Financial Services and we actually opened up a completely new department in Berlin (VWFS is usually in Braunschweig) mostly to get closer to the world of startups and interact with them. So it _is_ reaching the big companies here, the Volkswagen Group is starting to have a lot of new departments here in Berlin. It's awesome to see because there are a lot of motivated people within the brand that want to work like this. It also seems like the minds of our managers are changing on the topic and they quite enjoy what we're doing here so far.
It's way too hard to get anything that requires OpenSSL to work, I decided not to write Rust code on my windows PC because of that. I remember the process of just getting it to work as really painful and time consuming.
Other than that I really enjoy writing rust code on my Linux machine.
Fwiw, native-tls [0] is intended to solve this problem for the set of uses involving TLS (e.g. hyper [1], reqwest) by using the defacto standard on the platform you're on. This means no openssl is necessary on Windows.
Longer term, I would like to see some way for a crate consumer to optionally replace openssl with ring [2] where possible. But that's a harder problem, figuring out a common interface, specifying two crates satisfy that interface and are swappable by cargo...classic package management problems really.
Oh god yes. This is one of the reasons i switched back to Go. I wanted simple cross compiling, it was really important to me, and OpenSSL is just too commonly needed to run into problems for me.
This confuses me a bit, but I honestly have not spent a ton of time with Go, so perhaps you can explain. How exactly do you get simple cross compiling with OpenSSL using Go? Once you use an external library don't you lose all of Go's cross compiling simplicity?
For me it was only stopping my investigations into hyper and other web stuff (on windows), just writing CLI and GUI apps works fine on Windows. (I use VS Code and a git bash)
We are similar in size for our Angular2 application. We've also had very similar problems, especially setting up AoT compilation took pretty long and was a painful process.
What makes it difficult and what can we do to make things easier in the future? Is this something the @angular/cli should consider making default so as to surface pain points in as many scenarios as possible?
There just isn't enough documentation/articles out there on implementing AOT compilation. A lot of people are not using the CLI, since it wasn't mature enough when they started their Angular applications - Webpack is quite common these days. There is a nice plugin for Webpack maintained by the Angular team, @ngtools/webpack, but when trying to wire it in, the error messages are cryptic.
I was fortunate to have some key help at times from Rob Wormald of the Angular team, giving me some key insights about making sure my classes, interfaces, etc. are all exported publicly so they can be statically analyzed, and making sure to split my webpack configs & tsconfigs for dev & prod builds since AOT compilation is too slow for typical dev workflows (although you also want to be able to do it on dev to debug AOT compilation related errors) - I ended up with 4 different webpack configs for sanity's sake.
That said, the CLI does support AOT compilation and has that support built into it now - if I were starting an application now, I would probably just use the CLI.
We use cucumber at work for a few weeks now. Our product owner actually writes the initial feature files for our end-to-end tests and we refine them. We keep sending him back on what we changed and why, and the product owner learns from that and tries to do it the next time.
We started doing this around 6 weeks ago and it is helping us developers a lot in my opinion, as well as getting some work off of us. Sure, we need to refine the POs feature definitions, but it's better than nothing.
Before the feature files get written, have a conversation with the PO and other stakeholders.
Involve a QA person and relevant developers.
Catch the changes early, ask for more examples of the feature or goal, "have you thought about ...", "What happens in this case...?".
You will get better quality features with less rework, because you are writing the thing the PO actually wants and cover off edge cases before they crop up in testing.
If you take the ICE, definitely not slow. I commuted between Hannover and Berlin for the past weeks and it takes only 1h 40m for each trip. Driving would take close to 3 hours. I'm lucky enough to have a BahnCard 100 paid by my employer, though.
Except Hannover Berlin is more or less the same as Paris Lille. Paris Lille is under 1h and the price never exceeds 35 euros (which means you can sometimes find tickets under 20).
Now compare the prices with the price of everything else in France and Germany and you'll see why I say that trains in Germany are terribly overpriced.
(disclaimer: I work at Volkswagen)
Volkswagen also announced that 9,000 new jobs will be opened up with at least 1,000 of them being in the IT department in Wolfsburg alone. I wouldn't call this bad news.
I don't know why the IEEE is always such a downer about employment, but this article is stretching it the furthest I've ever seen. VW layoffs, especially if they come in the form of factory reductions / closures, could hardly be counted as 'tech industry'. Then, the actual layoffs that they tabulated at bottom of article are all significantly less than predicted. I assume it's tied to their anti-H1B lobbying, but it's getting pathetic.
If only for the sake of managing the Overton window, it's good to see some counterpoint to the cries of "There's a terrible shortage of programmers [at the price point we want], we desperately need to increase [H1B quota, bootcamps, etc]!!!" that periodically bubble up from the Big Tech submarines.
Just a nitpick but I think you meant "disclosure" instead of "disclaimer". Disclaimer would be to signal you are not sure the job figures are accurate for example. Disclaimer: English isn't my first language.
that being said, Volkswagen certainly is pushing electric vehicles now, all internal talk, newsletters are about the MEB (modular electric "toolbox", same as the current MQB for our conventional vehicles). The next investment meeting for the following 5 years is this november, a lot of money will certainly go for investments in electric vehicles.
Concourse also isn't really made to work well with the Git Flow, there is no builtin way to run the CI on multiple branches (there's a git-multibranch community resource which requires redis at some point). we're basically thinking about changing our workflow to trunk-based, but it still feels weird to me that we might change our workflow to fit our CI better.
that being said, I personally still really like concourse and it's fun to work with.