For us, a few weeks ago Azure DevOps randomly stopped processing GitHub webhooks, so merge commits didn't trigger builds anymore (and we're not the only ones, see https://developercommunity.visualstudio.com/content/problem/...). A fix for this issue still isn't deployed.
Just a few days ago the service connection to Azure suddenly stopped working with "401 CouldNotFetchAccessTokenForAzureStatusCode" which appeared when deploying to Azure AppService. We had to recreate the service connection to get it working again.
Recently we also wanted to move our Android builds to Azure DevOps but in the end the documentation was so confusing that we just used Bitrise instead.
It does not work unless Github is open to the internet. For example, Github Enterprise behind a VPN will not be able to use Azure Devops. Crazy but true.
I have a late-2016 Razer Blade and every time I compile something the fans spin up to aircraft-turbine levels of noise, it's ridiculous. I'm currently thinking of throwing the whole thing out and getting a Macbook Pro instead, because it's basically the loudest thing in our office.
You can disable the indexing of the whole GOPATH as of 2018.1 and it will finish indexing a whole lot faster. See Settings | Go | GOPATH | Index entire GOPATH.
Clusters come up faster. They're easier to upgrade. Don't have to delete clusters to change them (just provision a new node pool). Persistent storage is less weird. No RBAC. Weirdness around kube-system namespace. I.e. if I create a registry there, it gets disappears with no logs or events suggesting why.
That's what I really don't like about Azure.
They seem to have multiple differently named services that seem to basically do the same thing (Azure Service Bus/Azure Storage Queues is one example that comes to my mind)
Also, the Azure Portal is ridiculously bad and slow.
I actually like the Azure portal more than AWS. The speed is annoying yes, and n-level menu structure was overwhelming at first but the ability to manage all services from single SPA makes it much better than the way AWS console handles it, also the ability to minimize and do multiple actions at the same time balances out the slowness.
> The downside to this is that making a UI seems to even out your gained time--it's extremely messy and even complicated. Code that's valid in C# produces vague underwater bugs in Java code, which makes you keep hacking around until you find a working solution.
Interesting, I had the exact opposite experience, since the Java->C# mappings often reduce much of the boilerplate code that you have to write if you were using Java (e.g C# events, properties, etc..)
I also never came across any bugs in the mappings, but I can't say for sure that there aren't any.
Most of my problems often come from constructors. For example, using a custom parametered constructor in an Activity or Fragment seems impossible, so constructor injection is already out of the question. This is valid C#, but will not compile. Hence, I stated that using Xamarin feels like programming Java in C#, which makes me feel like I would actually be happier writing Java code.
Instead, for this example you could subclass Activity/Fragment and use reflection to find properties on the activity to inject services into.
This is only one of countless annoying Xamarin problems I have encountered in my few months of use, and this one was relatively easy to solve.
Vague problems also ensue when forgetting to inherit a class from Java.Lang.Object which leads to vague exception messages like "Specified cast invalid".
Sure, sometimes parts can be made faster in C#, but more often than not I spend day(s) debugging extremely vague bugs related to non-documented mappings.
Agreed, people seem to think Xamarin == Xamarin Forms, while the real power lies in shared business logic with native UIs, in my opinion.
Xamarin Forms may be useful for internal super-CRUD LOB apps that really are just a collection of input fields, but as soon as you do anything customer facing, you should be using the standard native UI approach.
Also +1 for ReactiveUI, it completely changed the way I build apps for the better.
Read it again, he found the password in cleartext in the memory dump. From the blogpost:
> I tried the small dictionary john.dict that comes with John-the-Ripper, and it didn't find anything. But of course, I don't need a real dictionary. The password is probably also in the clear in the memory dump. I could just use the file super.txt as my dictionary! I tried this, but it was taking a long time, with 150k unique lines of text. It'd take many hours to complete. To speed things up, I filtered the list for just lower-case words
Just a few days ago the service connection to Azure suddenly stopped working with "401 CouldNotFetchAccessTokenForAzureStatusCode" which appeared when deploying to Azure AppService. We had to recreate the service connection to get it working again.
Recently we also wanted to move our Android builds to Azure DevOps but in the end the documentation was so confusing that we just used Bitrise instead.