224 karma · joined November 7, 2020
Exactly, people should take the time to study different techniques, learn about their advantages and disadvantages, and then use some basic common sense when choosing a specific technique in a specific context.
“someone else’s computer” _is_ infrastructure. _everything_ you run in cloud runs on someone else’s computer. Besides, you need to specify the amount of cpu and ram you need for your lambda, the kind of scaling you want, whether you can live with a cold start or not, optimise that cold start, potentially configure networking and so on. You can claim all you want, in the end it is an extra piece of infrastructure that you have to be aware of and configure.
> You don't change the way your system is deployed or is operating if you run your background task as a lambda.
Seriously? You do not need some kind of authentication to call your lambda? The lambda does not need access to some kind of private data to store its results? You won’t introduce a queue or something to offload background tasks?
I think it is naive to state that introducing lambdas into the architecture of an application does not have an impact on the infrastructure you need for it. And it makes me honestly wonder how much experience you have with lambdas or functions on production systems.
No, I feel the same. It really is a completely different mindset compared to .net framework. And I believe it is recommended to keep upgrading, even in maintenance mode. I noticed that Microsoft removes target frameworks from their nuget packages as soon as they are no longer supported. That could be problematic if you need a security update and are on a no longer supported target framework.
An “enterprise” environment that is used to Microsoft products is not used to that.
Btw, regarding Postgres support: the guy maintaining the Postgres .NET drivers works for Microsoft on Entity Framework Core.
Regarding the boilerplate and the minimal hosting model and the minimal api… it starts to look like a nodejs express setup. Personally I think boilerplate was not that bad to begin with and saving a couple of lines of code (sometimes at the cost of legibility) is not worth it for me in a decent sized project.
I think you are right. I worked, and still assist, on a couple of big projects that are built on .NET Framework. I recently pushed to have those upgraded to the latest .NET Framework version, latest version of their libraries, and have the csproj-files upgraded to the new style. Those projects are all WCF, they use NetTcp, they use transaction flow over WCF, some use WCF-msmq. There is a big dependency on distributed transactions over service boundaries, sql server and queues, and on WCF. It would be a major effort to rewrite those to run on .NET Core without distributed transactions and over HTTP APIs.
Those systems have been running just fine for over 10 years, are deployed on-prem and are only used internally on the company network. As long as .NET Framework is supported, there is no value in a rewrite to .NET Core for the business.
In the company where I work, we actually do C# on .NET Framework (maintenance, support) + Core (all new projects), Java, Delphi, and Angular + TypeScript for frontends. We use a lot of the JetBrains tools: IntelliJ IDEA for Java development, WebStorm for frontend development. We used to use Visual Studio + ReSharper for C# development and since Rider came out, a lot of people moved to that.
I believe a lot of companies are not directly paying for MSDN licenses, but retrieve them for free through a Microsoft partnership and by fulfilling conditions to obtain silver and gold competencies. I think this is the case for a lot of smaller companies.
Microsoft however is changing their partnership conditions by focusing more and more on Azure. To be able to stay a partner with similar benefits, you basically need to generate more and more revenue on Azure for Microsoft. Something that will not be doable for a lot of smaller companies in my opinion. And this also depends a lot on the focus of the company, whether it is a pure software development shop or also a reseller of Azure services.
Besides that, .net development is no longer necessarily windows development. My current team consists of 6 people. 1 uses Linux, 2 use OS X, 3 use Windows. We use Rider, Webstorm and Datagrip. We develop .net backends that run on a Linux app service plan. The front end is in Angular. The database is postgresql.
A lot of the .net developers in our company asked to use Rider instead of the VS they get through an MSDN license. Most of them are Windows users. Some people clearly think Rider is superior to VS, myself included…
Well said! Even if you use an ORM, you definitely should still learn SQL.
It is also a good idea to keep a sql profiler open when working with the application to see which queries are generated. When you do that regularly, you can often fix issues before they really become a problem. This is also useful even if you do not use an ORM. For example, an action might execute a loop with a query on the inside of the loop. It might be more performant to retrieve the data using one query and then loop over the results of that query.
ORM should definitely not be regarded as a technology that allows you to use SQL and RDBMS without knowing those technologies. ORM should be regarded as a technology that can make you much more efficient when using SQL and RDBMS, when you already have good knowledge on SQL and RDBMS. An ORM should help you with all the 'routine' SQL stuff. And a good ORM will support you using straight SQL whenever you want to do something that the ORM does not support well.
I love LINQ, but I've noticed that there are people that think they know LINQ, and then think they can use an ORM because of that. And in the end, they do not really know LINQ, they do not really know how an ORM works, and their code generates SQL queries that have really poor performance. And then the obvious conclusion is that ORMs are bad. Well.... no, they are not, they are very powerful tools, but it requires knowledge to use them well.
Indeed, but the issue is that the phone manufacturer no longer supports the phone and release OS updates. And on Android, you could install unofficial mods to upgrade to a more recent version of the OS, but then some apps (banking apps for example) refuse to work because of... reasons, again making the phone unusable. And in a majority of cases, this has nothing to do with the hardware no longer being capable.
For this kind of thing, I specifically want something that stores the data locally, that is not part of the browser, and that is open source. Those things together make me more confident that the software is probably ok and can be trusted.
I am a .net developer and run Debian linux on my work laptop since ages. Keeping the OS and most of the software up-to-date is just "apt-get update; apt-get dist-upgrade". Microsoft has Debian packages for teams, skype, powershell-core, .net (core), azure-cli. Google has Debian packages for chrome. I use a lot of JetBrains' tools and keep those up-to-date using the JetBrains ToolBox. Where I work, we use Google workspace and Slack and I use those through chrome.
Just to be clear, most of my development is currently done on Linux using Rider, but I do have a Windows VM (on KVM) for older projects that run on .NET full.
The issues I come across, are related to our customers. For example when I am on location and need to connect to external hardware. One example is to connect wirelessly to a WiFi Direct display: this does not work for me and I did not investigate if there are drivers available or not. Another example is DisplayLink to use an external display through a dock: this I checked and there are drivers available and I did have it working at some point, but it broke after a kernel upgrade and it's too much bother to fix it again. Also for some customers we can connect remotely to their systems over VPN, but not all VPN solutions are available (or work out of the box) on Linux.
In any case, for my day-to-day work, I don't have any issues at all on Linux and I believe it's very very capable for coding, tooling and other work stuff. I definitely prefer it above Windows and Mac.
The mentioned aFreeRDP seems to require at least Android 5.0.
As Linux distro, Debian has been my favorite since forever (Potato). The last couple of years, I used to run Debian Stable, but I went back to Debian Testing on the Dell Precision 7670 for better support for the Alder Lake cpu and graphics.
I am a software engineer and work mainly with .net; mostly cross-platform .net 6 nowadays.
Regarding the 7670:
- love the screen (1920x1200)
- love the look and the weight; thinner and lighter than the previous generations
- I like the big trackpad, allthough I miss the physical buttons (middle click is very difficult in a dim environment, because you have to aim about right in the middle of the bottom of the trackpad)
- I was suspicious about the keyboard, but I'm pleasantly surprised: I like typing on it
- why-oh-why does every laptop vendor always try to be "innovative" with the keyboard?
- I hate the half-size up & down
- I'm happy that the num-lock got a light to indicate whether num lock is on or off
- I hate that "home" and "end" got dual function with "F11" and "F12"
- I hate the position of usb-c + headphone out on the right side of the laptop: that specific usb-c port is the only one that can be used for an external screen; if you want to use those, the cables are right in the position where you would use an external mouse (honestly, no one at Dell noticed this??); this is annoying because I usually use an external mouse (even though the trackpad is decent)
I really think that is the state of the matter.
Personally, I have been using Linux as main OS since 2000, so when I buy new hardware, I know it will be running Linux and I do my research on the hardware before buying anything. When you do that, chances are you'll end up with hardware that is supported and works well on Linux. The last 15 years I have been using high-end Dell Precision laptops through my employer and those run linux just fine; it's already been several years now that you can actually order them with Ubuntu.
Still, I've been on location where they used USB-C docks to access external screens and the network. The network was working fine out of the box, but for the screens I needed to install DisplayLink drivers, which was not a nice experience. It also did not work out of the box with xrandr. And then I got a linux kernel upgrade and it was no longer working. So, while the laptop itself is working just fine on linux, and is working out of the box with external screens connected through a cable (HDMI, DisplayPort), you still don't have good support for something like DisplayLink, which seems to be used more and more because it allows user to project wirelessly on a screen.
I try to avoid depending on closed source drivers in Linux. I did use Nvidia long time ago, but switched to AMD for that reason. In a way, it's nice that companies support Linux and that they are releasing closed source drivers. It is better than not having any driver at all. But depending on closed source drivers is misery sooner or later, so I avoid them.
I think that is a good observation that I also made and I want to add to that. Moving from a monolith to microservices, is moving the complexity from inside the monolithic system to the interactions between microservices. This means that the job of developers becomes easier since a developer only has to think in terms of the microservice he/she is developing and ensuring that that 'simple' system externally behaves according to spec. But it also means that the job of the architect becomes more difficult because he/she has to get a grasp on all communication (synchronously/asynchronously) between the different microservices.
So, even though there might be more complexity overall, I do believe that from the point of view of a developer, the complexity is lower.
If you know both the ORM and SQL well, you can save a lot of time during development. I've been using NHibernate for over 10 years and now also getting into Entity Framework Core.
I did see bad usage of ORMs and this was always caused by either a lack of SQL and database knowledge, or a lack of knowledge on how ORMs work.
- /organizations/:organizationId/blogs/:blogId
- /organizations/:organizationId/blogs/:blogId/sections/:sectionId
- /organizations/:organizationId/blogs/:blogId/threads/:threadId/comments/:commentId
I do this because it expresses the structure and the constraints of the data. A blog cannot exist without being linked to an organisation. And then you typically have the following CRUD endpoints:
- /organizations/:organizationId/blogs, with GET and POST to retrieve a list of blogs belonging to an organization and to create a blog for an organisation
- /organizations/:organizationId/blogs/:blogId, with GET, PUT and DELETE to retrieve, update and remove a blog
The fact that you always have the :organizationId in the url likely means that you can easily verify authorization, because I assume you would have a link between the user and an organization and maybe that link would already be available in the access token.
I don't think it is a problem that the urls are heavily nested. The urls are not supposed to be manually entered, but are using from within an application. I like the use of HATEOAS links, because I don't really like the frontend trying to assemble urls by itself.
Also note that next to the hierarchical links, you might need some extra for search that are not hierarchical. For example, say that there is a need to search blogs across organizations. This could be provided using the following:
- /blogs?description=test&language=en
You can provide a search endpoint in the root for blogs. This endpoint could then return some kind of blog object with a reference to the actual blog location (like /organizations/34/blogs/11). When you use this approach, the frontend has no need to assemble urls and the structure or complexity of the url does not matter. Do note that the frontend still needs some generic "start" urls like the blogs search endpoint.
Additional advantage (like others have mentioned), is that with the hierarchical urls it becomes more difficult to "guess" an url. Altough, if you want to properly protect against that, you should transform the ids before putting them in the url and transform them back when reading them out of an incoming url, for example using symmetric encryption with a secret only known in the backend.
Exactly. Maybe that was not clear from my comment, but my point is basically that using the most fancy tools is not gonna help a lot when you don't start with getting an understanding of the code.
Still, for me personally, I need to study the code and know what to expect before I start the debugger. It makes the debugging session a lot more useful and efficient. And, actually, like John Carmack said that other people told him, in a way, I do "replay" the code in my head while reading it. And a lot of times, I already figure out what the error is when reading the code. But, I will often still debug the code to verify that what I'm thinking is true: I do trust the debugger more than my brain.
Aside from that he also mentioned that nowadays software systems tend to be complex and too big to completely fit into one's mind. I agree with that, but IDEs make it easier to isolate the code in the system that is relevant for the issue at hand: you can find the call sites of a method, the use of results, the origin of input values and so on. I don't know how good IDEs are currently for C/C++, but those things are standard for C# and Java. And with those tools, it really is not that hard to get a rough view on where and how a piece of code is used in a big system. Obviously, this will be easier in a well-designed system than in a spaghetti-code system.
It is important to know all the contexts in which the code you are debugging is used. Often people are focused on the one specific context in which a user saw a bug, and they focus on that, start a debugging session for that, fix the code for that and break the usage in the other context... because they do not take the time to read and understand the code. And that is also where unit/integration tests come into play.
So, nothing against the use of good IDEs and debuggers, but always be sure to understand the code you are changing.
It's been a long time since I used C, but I wonder whether VSCode really gives a better experience than Emacs. Nowadays you can use Emacs with an LSP server, which is likely also what VSCode is doing. And there are Emacs distributions like Spacemacs and Doom Emacs that take away the configuration pain. As someone who has used Emacs for a very long time, I'd be tempted more into looking at CLion from JetBrains instead.
Regarding the comment about the debugging. For me personally, I always take the time to study the code first before I start debugging. A lot of times I already find the problem by just reading the code and even if that is not the case, I have a much better understanding about how the code is supposed to behave and that makes the debugging session a lot more useful.
And I say that because I have the impression that it is common for developers to dive straight into a debugging session without a good understanding of what the code is doing or trying to do. It's like they see the sympton and want to fix the sympton instead of fixing the core cause.
But that might just be my background with garbage collectors: in that case the sympton only becomes visible a long time after the actual problem occurred. The sympton was often dereferencing a pointer that failed, while the problem was the garbage collector writing a wrong value for that pointer in one of the earlier garbage collections. And that led to a lot of assertions in the code to catch problems early on.
It is still working fine for what I use it for. I don't need a flagship phone. Most important is that I can use it for calling, google email and calendar, google maps, waze, ebooks. It is nice to be able to use a browser on it, but honestly, on a phone screen a lot of web pages have 20% useful content and 80% commercials that stay in place during scrolling. And finally it's also useful to use some "apps"... and this is more out of need than out of want: my impression is that a lot of apps are just a bloated repacking of a mobile page. A bit annoyed by all those companies that insist on having their own app for something that could be a mobile web page and in reality often is nothing more than a wrapper around a mobile page.
Long time ago, I was really happy with Cyanogenmod on an Htc Desire... never tried LineageOS, maybe I should try that to get a more recent Android, but not clear what it would actually gain me.
For me, it totally works on the desktop. And since I really want to use Linux as a desktop os, I take into account the limitations and live with them. That means I stopped using nvidia gpus and just use an amd gpu or the built-in intel. That also means that to this day I still check linux hardware support before buying hardware. I live with the fact that not all games are gonna run on Linux. I bought games from Loki, I was very happy with the work from Ryan Gordon (icculus). I am happy with smaller indie games that run on Linux, since I no longer have the time to invest in big AAA titles anyways. I am a software engineer myself and do sometimes contribute to open source projects in my free time, when something is bothering me enough.
Linux does not have to gain a big market share as a desktop os to become a success, it has proven itself and it is a huge success already. Even Microsoft is investing to make the use of Linux painless from within Windows. I assume that they are aware that certain development tools just work better on Linux and that deployment in the cloud most of the time means deployment on Linux. So if Linux on the desktop does not satisfy your personal requirements, you are probably better off using another os.
A lot of the issues that are mentioned in this list (and others) are often personal preference, just wrong, or well known. However, the thing that bothers me the most is new users insisting that Linux should behave differently than it has done for a very long time, because that would be more convenient for users coming from another os... and it 'has' to change so that Linux can finally become the major desktop os! I believe a lot of Linux desktop users use the os as a work(station) os and I think that there should always be some respect for existing users. And I say that both for new users coming to Linux and for existing Linux projects that want to draw in new users or just want to change things to change things. When you use a tool to get work done and get it done as efficiently as possible, there is nothing more annoying and frustrating than having to deal with unnecessary changes in your tools.
Completely agree. Also ext4 _is_ case sensitive on filenames.
I think that _new_ users of a system should adapt to that system and not the other way around. Linux file systems have been case sensitive from the beginning. Changing that now would break things for users like me who are using linux for over 25 years.
I don't know whether they went that far, because I didn't watch the video on the site completely yet, but when you work with the abstract syntax tree, every change becomes a manipulation on that syntax tree. When you think about source control, you can use that concept in there too and store the changes on the syntax tree instead of individual edits. And when you do that, you would get a lot smarter merging, rebasing and conflict resolving.
For example, suppose you have a variable and branch 1 renames that variable and branch 2 introduces a new use of the variable. If you merge branch 1 and 2, or you rebase branch 1 on top of branch 2, you will not get a conflict, but the code will be broken. If you work based on the abstract syntax tree, the merge would automatically do the correct thing.
Another example would be that branch 1 renames the variable to x and branch 2 renames it to y. In that case, you would get a conflict upon merge, but not upon rebase. (for rebase: last committer wins) In the case of the merge, the system would know that the conflict is the rename of a variable to 2 different names, and the user would be able to decide on which name must be used.
I think it's really an idea worth exploring further and could have a big impact on the quality of code and on the efficiency when working in teams.
I repasted, repadded, and thoroughly cleaned mine a couple of months ago. I did that because the cpu got pretty hot, even with low load. After the cleaning cpu temperature was about 10 degress lower. And it's not hard to do, because these machines are easy to take apart. I also replaced the battery recently (now 3rth one I think). And I should actually replace the CMOS battery, because it's completely dead. It's really nice laptop, the only drawback is the weight.
I really like the Dell Precisions and I think the more recent ones are also well-built. They are professional laptops and not cheap, but worth it in my opinion.