The mystical magical unicorn debug build...
-
Mystical elephants disguising themselves as unicorns...again. Fairly certain that is your problem. There really is no solution for this. Well, there is, but I can't mention it here.
Slacker007 wrote:
There really is no solution for this. Well, there is
As an old coworker of mine once said to another coworker "You know what you should do? You should go and get a job in health care." :laugh: I guess it would make this problem go away, sort of.
Slacker007 wrote:
here
I see what you did their :D
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
-
Yes, it feels that way and it doesn't sit right with me either. Nothing I can do about it anymore though. Hopefully I'll be able to locate the problem sooner when (not if) it happens again in the future :sigh:
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
Sincerely, I wish you the best of luck there. :)
To err is human. Fortune favors the monsters.
-
Slacker007 wrote:
There really is no solution for this. Well, there is
As an old coworker of mine once said to another coworker "You know what you should do? You should go and get a job in health care." :laugh: I guess it would make this problem go away, sort of.
Slacker007 wrote:
here
I see what you did their :D
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
Sander Rossel wrote:
I see what you did their
:-D
-
At first I thought you meant the source control, but that's called Mercurial. Maybe I should take some distance from programming :laugh:
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
-
This seems like a situation where you have put something back together, it works, and there are parts left over. It makes me uneasy.
To err is human. Fortune favors the monsters.
Could it be an accidental rebuild all proces clogged in mystery which did the job? Probably I'm approaching this too simple. No offense (ever) meant :laugh:
-
So I just had to move some Azure resources from one subscription to another. Started with my development environment and everything went well. Did the test environment and everything went to hell. Application didn't start... Just not at all. Checked the logs, nothing. Checked additional logs, nothing. Checked some other services that I had deployed, all worked. Did a fresh release from my build pipeline, nothing. Checked every setting my application needs, nothing. Did a fresh release from Visual Studio, nothing. Decided to try a debug build from Visual Studio... And all worked as though nothing ever happened! Set it back to a release build and all kept working. Did a re-release from my build pipeline and all is fine. What the :elephant: was the problem!? This thing just cost me a couple of hours, what the :elephant:, Mickeysoft!? :mad:
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
-
My guess is that it thought the build was already deployed in the new subscription. Same hash, no reason to deploy? Switching to debug changed all of items so it had to deploy?
Don't know. It should've been deployed. Did the same to my DEV environment without problems, but it broke in TEST. Maybe the debug build added some missing file that TEST somehow doesn't add. Who knows, and no way to know now :sigh:
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
-
So I just had to move some Azure resources from one subscription to another. Started with my development environment and everything went well. Did the test environment and everything went to hell. Application didn't start... Just not at all. Checked the logs, nothing. Checked additional logs, nothing. Checked some other services that I had deployed, all worked. Did a fresh release from my build pipeline, nothing. Checked every setting my application needs, nothing. Did a fresh release from Visual Studio, nothing. Decided to try a debug build from Visual Studio... And all worked as though nothing ever happened! Set it back to a release build and all kept working. Did a re-release from my build pipeline and all is fine. What the :elephant: was the problem!? This thing just cost me a couple of hours, what the :elephant:, Mickeysoft!? :mad:
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
-
This probably isn't very helpful, but your story has further cemented my resolve never to use "the cloud" for development.
I've had such issues on on-prem servers as well. Heck, I've had weird stuff like that during debugging on my development machine. Ask yourself if you're not just a cloud-hater grabbing every opportunity to hate the cloud :)
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
-
I've had such issues on on-prem servers as well. Heck, I've had weird stuff like that during debugging on my development machine. Ask yourself if you're not just a cloud-hater grabbing every opportunity to hate the cloud :)
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
-
I've also had weird problems like that on my own machine too but I feel (possibly unreasonably) that I have more control when my machine is right here.
stheller2 wrote:
but I feel (possibly unreasonably) that I have more control when my machine is right here.
If that's how you feel, let me tell you why you may not want that control and it really isn't about control anyway. Maybe you'll change your mind about the cloud a little (you don't have to migrate all your projects, but your expectations may be more realistic). First, imagine having nothing and now you want to run your own web application. I have a few customers like that. As a programmer, I can't install servers, but I can create an Azure account and run the web application in an App Service (€65, or about €50 if you only need the basics, or even €5/free if you need it really cheap!). In fact, running in an App Service on Azure requires me to publish in Visual Studio, which is like three button clicks. Or I can create (or automatically generate!) a pipeline in Azure DevOps, giving me the option to push my code to Git and have it released automatically. You could even replace your App Service with an Azure Function (or Logic App) and get 10K executions for free, if it supports your use case. I'll host a SQL database in Azure while I'm at it (€5 a month for a small one) and my customer has their own web application for about €70 a month. For that you get daily back-ups, free TLS/SSL certificates, auto-scale, a bit of storage, staging slots (for A/B testing and/or deployment without downtime), the works. You can, theoretically, run a whole lot of services for just that €70 a month. If things get too crowded and your app becomes too slow, you can easily scale up. You'll pay a bit extra each month, but it's a simple button click, rather than migrating an entire server or having downtime because you need to physically update your server. You could compare those costs to those of a physical server, but remember, App Services are easy and just work. A few button clicks and you'll have your own CDN (you probably wouldn't want a CDN on your own servers anyway). No additional configuring required, no updates, no hassle. These are by far the biggest costs, add a Storage Account, Key Vault, Service Bus, some Function Apps (for short, periodic or triggered code execution) and you'll pay short to nothing extra. With a Logic App you can easily create workflows that trigger on incoming mail, Tweets, various events in M365, a whole lot, and then process that data and move it to some output (all clickable, your manager could do this!). This is idea
-
stheller2 wrote:
but I feel (possibly unreasonably) that I have more control when my machine is right here.
If that's how you feel, let me tell you why you may not want that control and it really isn't about control anyway. Maybe you'll change your mind about the cloud a little (you don't have to migrate all your projects, but your expectations may be more realistic). First, imagine having nothing and now you want to run your own web application. I have a few customers like that. As a programmer, I can't install servers, but I can create an Azure account and run the web application in an App Service (€65, or about €50 if you only need the basics, or even €5/free if you need it really cheap!). In fact, running in an App Service on Azure requires me to publish in Visual Studio, which is like three button clicks. Or I can create (or automatically generate!) a pipeline in Azure DevOps, giving me the option to push my code to Git and have it released automatically. You could even replace your App Service with an Azure Function (or Logic App) and get 10K executions for free, if it supports your use case. I'll host a SQL database in Azure while I'm at it (€5 a month for a small one) and my customer has their own web application for about €70 a month. For that you get daily back-ups, free TLS/SSL certificates, auto-scale, a bit of storage, staging slots (for A/B testing and/or deployment without downtime), the works. You can, theoretically, run a whole lot of services for just that €70 a month. If things get too crowded and your app becomes too slow, you can easily scale up. You'll pay a bit extra each month, but it's a simple button click, rather than migrating an entire server or having downtime because you need to physically update your server. You could compare those costs to those of a physical server, but remember, App Services are easy and just work. A few button clicks and you'll have your own CDN (you probably wouldn't want a CDN on your own servers anyway). No additional configuring required, no updates, no hassle. These are by far the biggest costs, add a Storage Account, Key Vault, Service Bus, some Function Apps (for short, periodic or triggered code execution) and you'll pay short to nothing extra. With a Logic App you can easily create workflows that trigger on incoming mail, Tweets, various events in M365, a whole lot, and then process that data and move it to some output (all clickable, your manager could do this!). This is idea
I don't develop web applications, so most of that argument, however valid in other cases, doesn't apply to me. By the same token, I don't run production jobs, just development, so scaling up for bigger production loads doesn't apply to me. I'm also on a satellite internet connection with a data cap, which makes cloud computing very dubious anyway, especially with the size of test jobs I do run (billions to hundreds of billions of records, hundreds of gigabytes to terabytes of data). Now what about my available hardware resources? CPU/memory: My development server, purchased in 2019, has 2x Xeon Silver 4215 with 128 GB of DRAM; my test server, purchased last year, has 2x Xeon Gold 6326 with 256 GB of DRAM. Storage: My development server has 2.5 TB of Optane SSD, 1 TB of NVMe flash SSD and 1 TB of SATA SSD; my test server has 3 TB of NVMe flash SSD with 1 TB of Optane SSD on the way here from an ebay purchase. As for big data, my main home server has 2 TB of Optane DC persistent memory, which doesn't seem to be commercially available in the cloud at this time. My test server has 4 TB of Optane DC series 200 persistent memory borrowed from Intel; I'll buy some when it becomes available at a more reasonable price. I own all of this equipment outright (other than the pmem loan from Intel). So although I'm not disputing that cloud computing has its place, basically none of its benefits are relevant to my situation.
-
I don't develop web applications, so most of that argument, however valid in other cases, doesn't apply to me. By the same token, I don't run production jobs, just development, so scaling up for bigger production loads doesn't apply to me. I'm also on a satellite internet connection with a data cap, which makes cloud computing very dubious anyway, especially with the size of test jobs I do run (billions to hundreds of billions of records, hundreds of gigabytes to terabytes of data). Now what about my available hardware resources? CPU/memory: My development server, purchased in 2019, has 2x Xeon Silver 4215 with 128 GB of DRAM; my test server, purchased last year, has 2x Xeon Gold 6326 with 256 GB of DRAM. Storage: My development server has 2.5 TB of Optane SSD, 1 TB of NVMe flash SSD and 1 TB of SATA SSD; my test server has 3 TB of NVMe flash SSD with 1 TB of Optane SSD on the way here from an ebay purchase. As for big data, my main home server has 2 TB of Optane DC persistent memory, which doesn't seem to be commercially available in the cloud at this time. My test server has 4 TB of Optane DC series 200 persistent memory borrowed from Intel; I'll buy some when it becomes available at a more reasonable price. I own all of this equipment outright (other than the pmem loan from Intel). So although I'm not disputing that cloud computing has its place, basically none of its benefits are relevant to my situation.
In that case it's not so much about "less control". It also doesn't explain why you have cemented the resolve to never use cloud. Anyway, in your situation I probably wouldn't use the cloud either. Doesn't sound like a very good fit. What do you do, if I may ask?
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
-
In that case it's not so much about "less control". It also doesn't explain why you have cemented the resolve to never use cloud. Anyway, in your situation I probably wouldn't use the cloud either. Doesn't sound like a very good fit. What do you do, if I may ask?
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
-
Sure. I'm the CTO of 2Misses Corp. We've just received US Letters Patent 11,254,590 for our foundational invention of a heterogeneous hash table and have half-a-dozen other patent applications in various stages of the patent process.
That's pretty cool and looks really complicated (math isn't my strong point). It's also far from what I do in every day life (writing custom administrative software for various business clients). The closest thing I do to what you're doing is probably:
var dict = new Dictionary();
//or maybe
employees.OrderBy(e => e.Name);;)
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
-
That's pretty cool and looks really complicated (math isn't my strong point). It's also far from what I do in every day life (writing custom administrative software for various business clients). The closest thing I do to what you're doing is probably:
var dict = new Dictionary();
//or maybe
employees.OrderBy(e => e.Name);;)
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
Sure, that will do the same thing, just with slightly less scalability for billions of records. :) But really most of the complexity in the patent is the incredible detail needed to get a patent that might survive being attacked by big companies with lots of lawyers. The basic idea is very simple: packing several variable-length records into a fixed-length bucket, so you don't need a pointer to every variable-length record but can instead keep many of those records directly in the table. This saves space (fewer pointers) and time (fewer random accesses to storage or memory).
