It’s really sweet that these types of articles pop up from time to time. There’s a lot of power here. Problem is that so many people use ORMs which don’t support all the types, or have to support different databases, that we end up in a suboptimal position :(
That is one of the thing I love about SQLAlchemy, we use most of these without problem.
JSONB is really nice to use, fast, efficient
When people bemoan ORMs and the “impedance mismatch” and it being hard to formulate queries or to optimize them I used to think “what are you talking about, there’s nothing wrong with ORMs” and eventually I came to realize that I was probably very lucky to have mostly only used SQLAlchemy (and LINQ way back) or raw SQL for talking to DBs.
The CHICKEN PostgreSQL egg, which is not an ORM but “just” a database access library (a wrapper for libpq with several additional features, much like Python’s PsycoPG) has rich support for types. I’ve written a so-called “omelette recipe” (a tutorial) about this a couple of years ago.
Most recent project I did, the SQL and the data access code was done in plain JDBC access code in Scala. The SQL uses postgres types and one or two more specialized bits. It’s worked out reasonably well; a compare and contrast with the FRM and ORMs from Scala that I did later on revealed roughly about as many lines of code, but without the support for Postgres capabilities; adding those capabilities got very fiddly and brittle, so I closed down that line of work.
Fortunately, I didn’t have to try to target multiple SQL databases. That would be Very Irritating.
I have always maintained that the “but multiple databases!” rationale for ORM is meaningless – how often do large projects change their entire data persistence strategy? How often ought they?
It may be rare for a particular installation to change, but “works with the database you are already running” is a compelling sales bullet.
Several times a day. By which I mean, using SQLite in unit tests and so forth, while using PostgreSQL or similar in acceptance testing and production. If I couldn’t do that, I’d have to write much, much more mocking code to have the level of code coverage I have.
You would only have to run postgres locally instead of sqlite. The coverage would be unchanged, and you’d be able to take advantage of more powerful database features in your application.
It’s pretty much as @tedu said. Good luck breeding those lions (as the meme says) if you leverage Postgres heavily but many of your pitential customers run Oracle and their DBAs don’t want to add something new to the mix. An ORM is the easy way out.
Even then you may encounter interesting situations with the Oracle driver and long text, unless that’s fixed or not applicable in your ORM of choice.
It does suck people don’t usually run tests against their target db. I’ve seen big companies fsck this up with Django. It really isn’t that hard. Turn off fsync and Postgres isn’t even slow.
The Lerna Core team has reverted this PR and revert information and response can be found in #1633.
Also : “Effective immediately, James Kyle has been removed from the GitHub org and will no longer have the privilege of making direct contributions to the source code.”
I don’t know what to feel about it
I wish you could select the language to view it in as well.
I was thinking the same thing while browsing the site.
I’m pretty happy with https://github.com/dropbox/zxcvbn to show password strength instead of asking for a special requirement.
Lol, why are the OpenBSD Developer hats in Comic Sans?
[Comment removed by author]
e) it is amazing.
f) people love to talk about it (same for our use of CVS)
Am I correct in assuming that OpenBSD devs don’t even see the font because it’s not installed in OpenBSD?
Yes you are. I didn’t notice until I read this tread :P . fonts/comic-neue ftw!
Because Comic Sans is secure by default.
Because you’re using Windows or Mac OS X, perhaps? I’m font-blind, but I think all the hats have the same font for me.
Go to https://lobste.rs/assets/application-f21028a5d89aee384d4f175c2d3f848992965d1ac46a61b85b93692544988f5f.css and search for “openbsd_developer” :)
Yeah, I guess I don’t have that font. Which I think is pretty typical for most free OSes. So, I guess being able to see the font outs you as someone using Windows or Mac OS X or Android or iOS?
Any clue if any of these are on the way into ports? I didn’t see any obvious answers on their various webpages.
(Edit: you people are awesome.)
Are you asking if there are ports using pledge(2)?
Yes, there are pledged ports and the number is growing. Chrome for example. You can check which ports define # uses pledge() in their Makefile.
# uses pledge()
or if these language bindings found their way into ports?
Yes, some of them
If you look at the twitter conversation you will learn that:
I didn’t find any others with a quick scan. I do remember some chat on ports@ from a long time ago about ruby I think.
tl;dr things are getting there :)
I’m the author of the python version.
I’m waiting for pledge to stabilize a bit before polishing it. As you can see in the BUGS section of the man page “The path whitelist feature is not available at this time.”
After that I plan to see how things goes for real usages in python and eventually push it into ports.
lang/node ships with node-pledge ready and waiting to be used in regular apps.
I haven’t added the path stuff yet.
I wrote the C# implementation - the package manager it’ll go into is probably NuGet. I might also consider wrapping other OpenBSD specific syscalls (like sendsyslog) and putting it into an “OpenBSD#” project, or something.
I would like some advice on this, arc4random is that bad ?
I don’t think so. It wouldn’t be my first choice for a new system, but I’m not about to panic.
The latest attack, for example, which completely broke TLS, actually only recovers the first 256 bytes of plaintext. arc4random discards way more than the first 256 bytes. In short, TLS was broken not for using rc4, but for failing to use decade old rc4 best practices.
Thanks for the clarification
No problem on radeon 6850, dual screen, one rotated.