qxmat

As an independent software contractor I could say the same about Microsoft's Partner Network.

Unless I sit a myriad of different exams I can't advance my competency to Silver or Gold. This means my MPN default "Partner" benefit is restricted Azure AD Basic and I can't take a parallel Azure DevOps build with me to a new project.

Worst still, if I leave my MS Gold Partner for a start-up I'll lose access to the enterprise elements of Azure AD (SCIM integration, Azure AD Application Proxy etc). If I'm called out to support something I delivered I'll need to absorb the cost of upgrading my Azure AD subscription.

This wouldn't have happened with a separate state file. Additionally, as said below, plan + apply must be separated with a ManualValidation task to allow release administrators to manually inspect the plan output on a production deployment.

Terraform's "-detailed-exitcode" will help you tailor the pipeline if there's nothing to do (0 - plan success, no changes, 1 - error, 2 - plan success, changes).

I'm also of the opinion that prod/non-prod subscription and resource groups pairs should be "vended" to you by another department (i.e. you're a user not an owner). This prevents you accidentally destroying the entire hierarchy.

If you use Postgres + Redshift on AWS (via foreign data wrapper or dblink) it's worth noting that AWS has released recursive CTE support in Redshift. But with that said 9 levels of UNION ALL ought to be enough for anyone.

Once this is over consider looking at network topology as a security mechnism in it's own right. Professionally I try operate a subnet hierarchy: public, intermediate, private where there's no routing information between public and private and private has no internet connectivity.

I suppose what I really need is a way of invoking certain operations through the ASG interface immediately, not at end of a long distributed async chain.

My $0.02...

#1 Make EC2 Auto Scaling decisions faster - it's painfully out of sync with the AWS Console table. I don't mind paying for it. And while we're at it please can I get a metadata address REST API to signal CONTINUE?

#2 SSH keys are configured in cloud-init, there's no reason they can't be read from SecretsManger and rotated out of the box.

#3 Put $HOSTNAME/$env:ComputerName in the EC2 Console table - weird software like Azure AD Application Proxy uses it for registration and I'm fed up using SSM to query all Windows instances to find an errant machine.

... and one more. Please make CloudWatch an out-of-the-box sink for cloud-init logs. SSM Agent doesn't start on Windows until fairly late (after other services), so it can be pain reading logs out of %TEMP% if you've locked the network down and fully adopted SSM sessions/port-forwarding.

... and a final one - we need a "1-click WTF" button to help solve EBS/KMS issues. There's insufficient info in the UI. Dropping down to check the cli JSON output isn't a user-friendly solution. Azure does this better with their "Diagnose and solve problems" blade in App Service.

If you export your docker socket to the container you can avoid the poor performance of docker-in-docker

... and here I was thinking I was alone!

Can you expand on this?

To my knowledge - as a one-time lettings paralegal - we have some of the best tenancy rights in the world.

I've worked at productionising data science models for the past 4 years. I'm currently responsible for delivering technology platforms to ~180 data scientists.

I find the data scientist label misleading.

Roughly 70% of of the data scientists I've encountered are actually Excel analysts with little experience outside of a Windows desktop bar Facebook on a Mac. They're unable to use basic software engineering tools such as git, vscode and python. Excel users and their managers are hostile to solutions that aren't excel-like. They will fist-fight you if you restrict them from downloading and exploring data on their computer. Few understand their compliance/legal obligations.

Another 20% are familiar with a wide range of tools - such as Matlab, R, Jupyter notebooks and various ML/AI toolsets. As developers they're unaware of the tech stack, short of "I installed ananconda and it doesn't work" but are happy to work in the cloud and learn new tech. They understand PII requirements and memory/cpu limits but don't always demonstrate the latter in practice. Nonetheless they produce the bulk of your analysis, having studied classification, and reasonably cost efficient if you pair with a SWE.

The final 10% have mastered containers, venvs, wheels, cloud sdks and how to configure their software in environment independent way. They require help to achieve production quality but are great self-starters. Given enough time and support they're able to quickly replicate this effort and teach others. As relative superstars they're in high demand which makes capacity planning difficult. This pushes up their premium.

IMO the best data scientists are 1 in 10. Because we're desperate for quality almost anyone can assume the title meaning the market open to new comers - you just need to be skilled in Excel (harder than it seems - most developers can learn a lot observing an analyst/consultant use Excel).

To answer your question: No - you're not too late. Just by posting here I expect you'll be in the top 30% - an asset in demand.

I've seen auto-generated passwords break bash and powershell alike. Please include a way to bind variables to something not parsed as process arguments - such as a pointer to a env var, Azure KeyVault key, AWS SSM key or just the raw contents of a file.

Watch out for template expansion hell. Azure DevOps provide multiple types of variable expansion: macro, template expression and runtime - this helps but has it's own limits.

Also I found arg forwarding with '-' with node cli tools rather powerful lately.

This is what SSDT dacpacs offer (it's supposed to be an open standard too). Unfortunately they suffer similar issues as you describe (most data migrations are destructive).

I settled on flyway after migrating to postgres a few years ago and haven't looked back. The "this is great" moment came after we automated snapshot and restore of per-dev environments in the release pipelines - this allowed us to roll out the last released version of the product with either a clean database (fast) or a snapshot (slow) to our own individual database in only a few minutes. As a result we could test flyway migrations without the grief caused by breaking (or reverting) a shared 'dev' database.

Since moving on from that team/company, and run head first into dacpacs again, I've found it increasingly difficult to sell my past approach. Few people are genuine data experts, few still DBAs and almost no one is responsible for cross cutting concerns etc. I can't help but think empowering devs to automate migrations, even if it's a hackity SQL parser, is part of the solution and I'd love to see this take off.

The "stop solutionising" mantra in agile is equally harmful.

Liquidity problems?

I'm of the opinion that dishonesty is serious because it's an irreconcilable breach of trust. There are many things I'm happy to deal with internally providing there's a frank account but once someone intentionally misleads another it makes individual management untenable.

Separately it's a HR problem because of the nature of certain types of work. I'm struggling to fit my view with neural diversity though - some devs say dishonest things without malicious intent because they lack skills to effectively communicate.

1. get 2 mentors: a technical one and business one (doesn't need to be domain specific)

2. your job is transitioning from "doing" to "enabling". You'll be responsible for issues of governance AND operation. Learn the ropes equally. As you introduce successful operational concerns (bottom up) start to generalise them so they can be used as a top-down concern (i.e. i do devops -> we all do devops here, it's part of the training)

3. leading by example doesn't scale - stop. Embrace a teaching method that ends in trust: i.e. 1. introduce a concept to dev A, 2. get dev A to demonstrate it back to you independently (monitor and prompt as appropriate), 3. from afar passively observe future implementations of said concept and revert to steps 1..2 if required, 4. inform dev A that they are trusted explicitly with this concept and that it is theirs to run with - encourage them to onboard dev B in a similar fashion.

4. at the top you're more responsible for team morale than you can possibly imagine - random acts of kindness and/or direct conversations go a long way... whether it's donuts or "a quick catchup" over lunch, do it... regularly (if you find your postponing these kind of meetings you've got a priority inversion issue to sort out ASAP).

5. if someone is dishonest in any way take it to HR before they walk over you and your team/product/department suffers. In other words, with HR's help, address slow/no work or unapproved "wfh" days as a threat.

6. push back against harmful designs and rushed/skipped processes.

Thanks - I had no idea they were separate words!

I worry that the plasticity of my brain is decreasing as I age. I've begun to notice that my attention is increasingly difficult to manage. I haven't blamed HN (yet) but I certainly emphasize with the author.

Tangentally, as a young adult I had severe ADHD/ADD. I stopped taking meds for it after is ceased causing a negative impact on my life towards the end of puberty. Sometimes I wonder what would happen to my personality and creativity if I started meds again. Would I be the same, gain an unfair advantage or excel at things I've given up on?

Your manager sounds great.

Once you're able to outline the delivery/business/product case consider getting your QA function to champion (author?) the technical solution with you.

It's good to separate the two initially (a well documented problem leads to more options than a quick fix) but at some point you'll want to engineer buy-in. What you've described will almost certainly be a pain point for testers - this makes them great advocates for change and grants QA much needed ownership.

Feel free to dm me if you want to discuss this further.

We have a similar issue.

Generally speaking, your work must fit within a value stream - that is, to support your job/function you must do something that's rewarding (someone's got to pay the bills). There are a lot of interesting agile principles at play here but ultimately they revolve around delivery which must occur regardless of how complete, incomplete, fast, slow and/or viable your data is. Delivery is valuable. Your tech leads are the ones most clued up on what must happen and which compromises are acceptable. Their role is to get some data - any data - out so that you can make a qualified success of your product. Cutting corners and managing/deferring difficult decisions is part of that job.

Over time the cadence of features and the complexities of your data will require pivots. Initially you might have gotten away with simple line-level data but with maturity and agile planning the next revenue producing feature might require aggregation and complex transformations. Once again your role is at odds with delivery - if there's a simple way to make the end result a qualified success in the shortest lead time possible, data comprises ought to prevail over your immediate happiness.

Now with that said you might be thinking "wtf this is nuts - it can't be right... I'll never succeed". That's actually quite possible. It's often a reason why most developers move on. When that happens the process becomes self-destructive - new devs start and become disillusioned and leave creating an air of futility; product knowledge is virtually non-existent...all past decisions were shit and should never have been done that way in the first place etc.

So how do you fix this? I'm going to avoid the technical side because I don't know your stack. The procedural/operational solution comes from understanding and managing your employer's approach to agile. The big word here is Trust. Is your team trusted to manage the work items that enter the sprint? Are you trusted to add work items to the backlog? As developers do you own the sprint? Have you created items that address your technical concerns with concrete examples (it might take you several sprints to fully flesh these out)? If you answer 'no' to any of these it's time to address them and start owning the process. If you've tried this or you've failed to explain from a delivery perspective why you have problems and what their risk is (use past examples rather than future commitments) and there's been no traction you should consider quitting.

The current Mayor of London (Sadiq Khan), his religion (Islam) and immigration are unrelated.

Sadiq Khan is the Labour candidate who succeeded the previous Conservative mayor by majority in a democratic vote. Swings between the two major parties are common.

In other totally unrelated news, 12% of the population of London are Muslim.

Your reckless conflation of facts paints you as a troll of religious discrimination if not outright racism.

At Games Workshop we had a huge discount ~ 60% IIRC. Staff were regularly terminated for reselling - a big no no. If you were a hobbyist the discount was great perk to make up for low the low salary.

The share-save scheme, in hindsight, was amazing. You could buy at a good discount. While I was there it traded between 380 and 425p. Last year it hit 4000p. Currently at 3200p. Unfortunately I couldn't make ends meet on my salary there (even opting out of the workplace pension scheme). I try not to dwell on it too much but I really did miss out on easy money.

If you worked at the HQ you were fortunate to have an on-site gym. For £5/m you could join the "Sports & Social" group for access (local gyms were £40+/m). The balance was spent on cinema trips and bowling... great get-to-know-your-department events.

Oh, did I mention they also have a Dwarf themed pub with £1 a pint staff nights?!

We all moved to Macs for this very reason. Now I have a kernel thread that leaks ~1.7Gb over the course of 2 days if I 'watch' any assets but at least it's deterministic.

>> I shake my head when I see some bushy tailed developer using the repository pattern just in case the corporation decides to abandon their million dollar Oracle installation to go with Postgres.

The repo abstraction is a fantastic way of declaring your data access implementation and separating its concerns (especially limitations) from the service tier. Once declared - via interfaces - you can substitute the concrete implementation for something that suits the environment and the ever maturing agile use case.

Given how this is a fundamental scale/refactoring primitive, perhaps you haven't considered how others use it. I've used it time and time again at least 3 ways:

Monitor and consolidate data access patterns. If ITopSecret repo requires you pass an IUser to your verbs, you only need to audit/validate this layer to prevent unauthorised access. No one will replicate the query in IExportService and forget to check permissions again.

To scale read-heavy data, with new technologies like predictive search: Slowly pivot away from SQL sprocs/views to Solr/Elasticsearch by swapping out the concrete implementation ISomethingSearch repo with a new one.

For offline 'work' and unit tests: Create new concrete implementation of IBlobRepository that read/writes to your file system or an in-memory chunk.

I have an engineers understanding of higher maths - overly general and very patchy. Short of taking an undergraduate math course, are there any resources to help me parse math notation? For example, while brushing up on endogeneity/exogeneity, E[B'|X] = 0 completely threw me - I had to search Google for the use cases of a bar/pipe aka latex vert/mid. I usually lose interest in a paper if I get stuck trying to decode the syntax.

Solution Architect - https://jobs2.deloitte.com/uk/en/job/DELOA004X172284/Deloitt...

Software Engineering Lead - https://jobs2.deloitte.com/uk/en/job/DELOA004X172278/Deloitt...

Software Engineer (Mid + Senior) - https://jobs2.deloitte.com/uk/en/job/DELOA004X172266/Deloitt...

QA Engineer - https://jobs2.deloitte.com/uk/en/job/DELOA004X173982/Deloitt...

DevOps Lead - https://jobs2.deloitte.com/uk/en/job/DELOA004X172288/Deloitt...

DevOps Engineer - https://jobs2.deloitte.com/uk/en/job/DELOA004X172285/Deloitt...

So... adopt the UK model then?

Stop trying to make the perfect product: make something small and fail/succeed fast.

Once you stop being an external observer and commit to delivering a product, your understanding of the wider market will improve... before long you'll see profitability in places you didn't know existed.

There's nothing wrong in delivering something simple first. Most of the consulting businesses out there simply 'solutionize' Excel spreadsheets (i.e. add a web or mobile frontend to an internal process). Take the post room in my building as an example: they've just upgraded to an electronic system dispensing with the time consuming/error prone ledger entry and paper slip delivery. Someone sold them a 'CMS' with a package input form and email alert... As scope increased they added bar code scanning and a check-digit shelf allocator.

Large tech companies employ hollywood accounting techniques to continually reinvest surplus revenue. In doing so they rarely post any significant profit, depriving the taxmax of corporation tax.

This 'reinvestment' is used to compete and drive profitable competitors out of business. This is an unfair practice. The result - no profitable companies, smaller taxable base and nothing for the taxman to collect.

The bigger the juggernaut, the more influence they have on the taxman ("but we're contributing to pay/income/property taxes - surely you don't want us to relocate abroad"). Large multinationals use their corrupting influence to strike sweetheart deals and use these deal-made tax savings to abuse the market even more.

DECLARE @please VARCHAR(3) = '???';