81–89 of 89 posts
Earlier quoted context omitted.
There is a list of company success stories. [1] And a list of companies using Clojure. [2] [1] https://clojure.org/community/success_stories [2] https://clojure.org/community/companies
Good list, would love to hear more details about their success stories and use cases.
[1] http://blog.cognitect.com/blog/2015/6/30/walmart-runs-clojur...
This post makes no mention of the macOS part of the CircleCI infrastructure, which is one of the trickiest parts of infrastructure IMHO. Tricky because Apple's EULA prevents virtualizing on anything other than its hardware, never more than 4 VMs per host, and not for commercial purposes...
On the topic of QA testing/automation, it really kills me that Apple servers won't sign older iOS releases which means QA teams need to protect stock devices from accidental upgrades. The AWS Device Farm iOS devices are all jailbroken.
Earlier quoted context omitted.
I think the workflow is pretty easy: buy a MacBook & an iPhone, and load your app onto the phone & test on it for things which the iOS simulator is not good at. Don't CI your apps, CI your libraries.
> I think the workflow is pretty easy: buy a MacBook & an iPhone, and load your app onto the phone & test on it for things which the iOS simulator is not good at. > Don't CI your apps, CI your libraries. That's not scalable for complicated apps that you can write automated UI tests for though.
To me, what you described is an app that was not designed to be easy to test component-by-component & will have a high overhead on maintenance. Apple’s restriction on virtualising MacOS seems unrelated to how the app was architected, so it feels unfair to expect Apple to alter their position to better support something they weren’t responsible for.
Earlier quoted context omitted.
Urban Dictionary uses Clojure. We're really happy with it
Nice! You guys rock. Any blog posts to share about why Clojure was chosen and how it's working out for you guys?
Earlier quoted context omitted.
> I think the workflow is pretty easy: buy a MacBook & an iPhone, and load your app onto the phone & test on it for things which the iOS simulator is not good at. > Don't CI your apps, CI your libraries. That's not scalable for complicated apps that you can write automated UI tests for though.
Could you take the complicated bits and put them in a library? How complicated is your app? To me, what you described is an app that was not designed to be easy to test component-by-component & will have a high overhead on maintenance. Apple’s restriction on virtualising MacOS seems unrelated to how the app was architected, so it feels unfair to expect Apple to alter their position to better support something they we…
We have complex commercial apps with fully automated user interface tests (e.g. it'll test that you can enter your username + password, actually login and you'll be able to see content). You could test all the individual components as much as you want but you're still going to get bugs at the UI layer that you can automatically test for.
We do the same for Android and CI for that is so much simpler.
> Apple’s restriction on virtualising MacOS seems unrelated to how the app was architected, so it feels unfair to expect Apple to alter their position to better support something they weren’t responsible for.
You'd think they'd want to support workflows that led to better quality apps being created. Surely it's their responsibility to support developers?
Earlier quoted context omitted.
It's not a strawman at all- many of us who run Clojure have had to switch to other langs for parts of our infrastructure that require faster start-up time. Think Lambda / "serverless" computing, etc Agreed it doesn't help with static dependencies, which is why I didn't mention it ;)
It is a straw man - you're justifying your suggested solution by comparing it to something that is already considered bad in the area. That's exactly what a straw man is.
Many of us who actually run Clojure in production have been bit by this, and Clojurescript has been fast enough to alleviate the issue. Not a straw man, a community meme.
Earlier quoted context omitted.
Could you take the complicated bits and put them in a library? How complicated is your app? To me, what you described is an app that was not designed to be easy to test component-by-component & will have a high overhead on maintenance. Apple’s restriction on virtualising MacOS seems unrelated to how the app was architected, so it feels unfair to expect Apple to alter their position to better support something they we…
> To me, what you described is an app that was not designed to be easy to test component-by-component & will have a high overhead on maintenance. Apple’s restriction on virtualising MacOS seems unrelated to how the app was architected, so it feels unfair to expect Apple to alter their position to better support something they weren’t responsible for. We have complex commercial apps with fully automated user interface…
Surely you can prove the correctness with integration tests of your modules, and then your acceptance tests can be simple 'did the thing not show an error when we clicked on the thing, and it went to the right page'? We have 'simulate the world' 'acceptance' tests at work and they're terribly flaky, and I look back at the layered approach to testing we used in a previous job where the go-live test was to hit the landing page & search results page & check that the status code was 200.
To be fair, the kind of tests I'm proposing won't catch layout issues. But, neither will the tests you're using.
Earlier quoted context omitted.
> To me, what you described is an app that was not designed to be easy to test component-by-component & will have a high overhead on maintenance. Apple’s restriction on virtualising MacOS seems unrelated to how the app was architected, so it feels unfair to expect Apple to alter their position to better support something they weren’t responsible for. We have complex commercial apps with fully automated user interface…
> you're still going to get bugs at the UI layer that you can automatically test for Surely you can prove the correctness with integration tests of your modules, and then your acceptance tests can be simple 'did the thing not show an error when we clicked on the thing, and it went to the right page'? We have 'simulate the world' 'acceptance' tests at work and they're terribly flaky, and I look back at the layered app…
What made your UI tests so flaky? As long as the code for them isn't much beyond "enter text into text input X, click this button, you should be able to see this text" they're not too bad to write but the initial setup can be tiring.
> To be fair, the kind of tests I'm proposing won't catch layout issues.
Screenshot comparison based tools can be amazing for this as long as the way your app looks is fairly stable.
Automated testing is always a tradeoff with effort to setup vs the time you save (I'm against e.g. TDD for everything) but for complex apps and big teams it eventually pays off.
Some of our builds are running on CircleCI but have been trying out drone for a more container focused build. Been enjoying the flexibility and increased speed from custom build images which are trivial to make.
If you don't mind tinkering, I highly recommend Buildkite. They provide the management & cloud UI and you run the actual build agents on your own infrastructure. When you get it going it blows everything else away in value for money. We routinely have hundreds of containers on-the-go and as many concurrent builds as we need; this all runs on a large AWS spot instance at a cost of about $50 a month. Added bonus: our d…