I know the whole point of cloud services is to pick and choose, but in general I wouldn’t express “outrage” or scoff when comparing Azure to AWS. I recommend Azure to the smallest and leanest of shops, but when you compare functionality matrices and maturity Azure is a children’s toy.
To compare the other way, Azure write blocks target replication blob containers. I consider that a primitive and yet they just outright say you can’t do it. When I engaged our TPM on this we were just told our expectations were wrong and we were thinking about the problem wrong.
The goal of my question was about what are the differences between the two solutions: I know HN is a place where I can read technical arguments based on actual experience.
Perfect anwser. I have used DI for years, and the common DI abstraction is a great features: it allows people to start using DI and allow MS to use it internally, then, if you find it too limited or like some custom features, then start using a custom one, which is a breeze.
I shared the same frustration, but I finally gave up, and guess what, I was able to fulfill my projects and have a good insight about what my layout will be even with ~5cm difference. I learned to relax about absolute measures and think more about feeling and subjective dimensions.
Described in programming terms: You try to type the weird dynamic object you have to deal with in Typescript but after spending too much time, you learn to relax about types and just write it in JS and it feels like it's working most of the time.
Don't forget the power of `as const` and type guards for tricky dynamic types! Especially for function params that accept multiple complex object types.
Webpages and pdf (paged documents) are fundamentally different, you won't be able to support easily headers and footers, page-breaks and orphans on a webpage. You can create basic invoices on webpages, but anything more complex (and by that I mean any serious word document) will require you to twist HTML. Try to have column headers to repeat on each printed page on a HTML page.
The markup doesn’t need to be html - and would be better not to be. The point is more that templating languages are great for formatting data as markup and markup is great for driving layout. With this library as a backend you can make something super usable.
I believe browsers have been repeating table headers on printed output for some time.
Page media CSS is designed for this although most browsers don't fully support it, PrinceXML is the go to for full paged media support.
IMO they are not fundamentally different, they are both document formats, PDF just a has fixed paged rendering layout baked in while HTML can flow and adjust to rendering target. The main issue is lack of full print CSS support in HTML rendering engines.
Still, to switch back to the previous point, it seems it's more a divergence between using markup or code to design a document. Both have valid usage and benefits depending on your case.
In my case and my apps, I often need to handle complex conditions that fits better imo in procedural code (complex invoices and agreements). On other cases (reports), I prefer to use a markup language.
There are a lot of procedural tools for generating HTML, lots, if modern browsers fully supported print CSS then you could use them for complex PDF generation, or direct printing, either client side or on the server headless.
If your app is a web app this is a no brainer, the users browser could simply do the print or PDF conversion as needed.
I do see a use for more direct libraries in native apps, although if every native client had a browser control with full print CSS support even then it might not be such an issue.
If your app is a web app this is a no brainer, the users browser could simply do the print or PDF conversion as needed.
That's arguable, IME (and also a better UX), most would prefer to just get the PDF file which just one click than to deal with additional browser dialogs. No everyone knows how to do print-to-pdf or even know it exists.
Or do you mean browsers expose print-to-pdf functionality as an API?
Hitting print in the browser or calling Window.print() if you want to force the dialog.
If you serve a PDF you still need to hit print or use dialog to save, you can use a headless browser server side to serve that if needed.
I do think browser could use better print API's but you not getting around that with server side PDF's unless the server direct prints to on site printers or something.
I am not sure if it is a good idea to think about webpage and PDF content as the same. After all, they both serve different purpose and their layout shouldd be optimized for the use case.
None of these things are difficult at all with html. Plus you have the benefit of having the document viewable in a web browser too. You use the exact same html layout for both with specific css (heights, widths mainly) for each.
This keyboard layout, also known as AFNOR Azerty NF Z 71-300, has since be standardized. Drivers[0] are available and keyboards[1] can be purchased.
I am using this layout for more than 1 year for programming and writing in french, and it's really good. I find it even better that the international keyboard layout or qwerty.
The fact that they have considered both the programming language approach AND the natural language typing is a real pleasure.
Theres also (to my mind) some oddities around the inconsistencies around é and É, and ù and Ù where they use different modifier keys to choose the upper and lower case variations.
Tilde ~ was removed?
Ezh ʒ was added?
No doubt its better now you actually have the keys you need available for the language itself - but maybe it needed a bit of curation as to their selection and consistent modifier-key selection?
Even better, there are already "drivers" in modern Linux distribution, e.g. under GNOME you have to choose "Français (AZERTY, AFNOR)" as keyboard layout.
It's more expensive most likely because they're not outsourcing environmental and human rights costs. Also, they are not gathering and selling your data unlike many others.
The only reason it is more expensive is that people will pay the mark-up and they are a for profit company. There is no more reasons than that needed for it to be expensive. The $2 to workers is nice, but the main thing that is used for is marketing as you shared here which allows them to put another $20 mark-up on the item. Of course it is nice that workers gets better conditions, but you'd be better of donating that money instead.
They are outsourcing but they're specifically negotiating contracts that guarantee living wages, ethical worker conditions and ethically sourced raw materials, so that's gonna be factored into costs.
That's the change as of that blogpost: they're using their own initial costings as a baseline so it's still going to be much more than a $2 increase over average manufacturers.
I guess in a typical phone the display is basically a unit that is comprised of the glass, the actual display, and the digitizer sandwiched and glued together; that makes it more than a single component already. And the price difference between the iPhone and the Fairphone one might mostly be demand. There's probably a lot more iPhone display units out there than even Fairphones of all generations.
I have been using azure storage append blob to store logs of long running tasks with periodic flush (see https://learn.microsoft.com/en-us/rest/api/storageservices/u...)