@JohnK.N. I'd say that's a matter of opinion. When I say 'integration', I mean 'a couple of hours of faffing about to try and figure out why it didn't pull from the branch you just went to pull from.'
Followed by a couple of hours of faffing about to try and figure out why it's got a merge conflict with the branch you thought you just pulled from.
And then followed by an uneasy feeling wondering whether you've just committed what you thought you just committed.
Followed by the build guy faffing about for two weeks trying to clean up all the sh1te it's dropped on the floor with merges overwriting or dropping changes.
@PaulWhite Pretty sure the Linux kernel wouldn't be what it is if git did behaved like this natively?
I'm sure that if you use git as it's meant to be used it probably works fine. I'm less convinced that VS's git integration plays all that nicely with the way git itself wants to work.
Unfortunately, what it's actually doing is quite opaque.
I feel what I'm doing should work - copy to a remote branch, pull from remote branch, make changes, push. However, when I just did this today it found merge conflicts between the remote and local copies that should not have been there. They should have been pulled when I got the remote branch.
Not sure why that happened, and it gave no feedback about what it was doing.
And it's not the first time it's done that sort of thing.
Partitioned Table Question.
When creating indexes on a Partition table ( Fact Table) , we always include the column that is the basis for the partitioning in the index. This column is also ALWAYS used in the where clause when accessing the data.
When creating the primary key / non unique indexes...
@SeanGallardy Sorta kinda, I think. IMO the underlying driver is the use of shared storage, which a cloud platform has to be doing, by definition. In a lot of ways we're back to the 2000's where blade/SAN infrastructure first started trending hard.
@ConcernedOfTunbridgeWells Depends on the service, not everything uses shared storage. However I feel you, feels like ISCSI all over again on a san for sure.
@ErikDarling lol, I saw billing for a non-critical tier VM with 8 cores and 16 GB of ram the other day and just about fainted. I could outfit a waaaaay faster machine for far less money.
@HannahVernon I've seen my share of horror stories about cloud billing. Now, we have the rise of a cloud architect, somebody whose job it is to optimise cloud usage to minimise billing. Back in the mainframe days, this role used to be called a capacity planner. We've had a brief golden age where infrastructure was cheap enough not to need this, but now we're back in the dark ages.
@SeanGallardy now, if you have a very variable load that needs horizontal scaling on a whim, cloud might be the way to go, but I have my doubts that even that use case would be cheaper in the cloud, unless sub-millisecond response times are critical between the app in the cloud and the client web browser requiring multiple data centers around the world.
With the corollary that 'flexibility' is a lie, because now you're going to have to get signoff from a bureaucrat and prepare a business case in order to get more server capacity.
I'd noticed something similar. They powers that be have outsourced managing the azure estate to a third party, and getting them to do anything is somewhat time-consuming.
Even little things like permissions or firewall settings.
Agreed; we're in a similar situation, where they are supposed to be steering us in an efficient direction, but instead they are always relying on us. One of our in house architects is going to Portugal for 3 weeks in May and they practically died when we told them about it.
And this is a global consultancy specialising in Azure
@HannahVernon everyone loves to think they need that... except rarely does anyone but the largest of large companies due and even then they rarely scale they just leave everything up and running.
I can say I've had processes that I'd like to have run faster, but in practice a fairly ordinary on-prem server of decent spec would have had the I/O for the task.
The business-critical tier of Azure SQL has storage claiming 1500-8000 IOPS.
My PC has a SSD with a nominal rating of 600,000 IOPS.
A middle-of-the-road Adaptec RAID controller has a nominal rating of 3.5 million IOPS.
I have a working hypothesis that most big data analytics requirements could be met with a midrange workstation and a copy of WEKA.
@HannahVernon It's a data mining tool developed at Waikato University and now punted by Greenplum or somebody like that. The other player in this space is Clementine, now known as SPSS modeller and flogged by IBM.
And in the worst case you could build something with Numpy or R. R is quite slow on large data sets, though. Numpy uses BLAS in the RS end, so it's got nice, quick matrix ops.
Seriously, who actually has a 100TB of data for anything?
They both compile to native code. Go has a garbage collector. Rust has a gnarly type system and ownership lifecycle management features that eliminate various categories of memory related bugs while remaining efficient.
C++ is naturally adopting the nice features from Rust, in much the same way that it's adopted features from every language.
