Generally I agree with most of the submissions, but this one is the most important.
I really love debian because of its principles (and I would love to contribute), but I feel that new contributors (like me) have problems because of the many (and some old) tools and outdated and non-friendly documentation.
Also, I don't know how many contributors come and stay, but even in unstable I see some outdated packages in weeks, and also some useful software that is not packaged.
I don't agree with this.
NGOs are primarily meant to do (morally) good things to the society where we live (usually help helpless people), where corporations pursue profit, which is usually not a bad thing unless they break the law (with a misleading behavior with the customers, antitrust, tax evading, and I'd like to say also lobbying).
Anyway, Steam users are also paying to consume the game, even if they don't own it. And I really doubt the 2% of their users read even the first paragraph of the EULA contract (where they do specify the above, yep I read it.)
Curious enough, years ago I've seen a blog post where the author used PNG lossless compression for FLAC audios.
Guess there should be a lot of room for improving both image and audio compression, even because we're still ending up using jpeg and mp3.
We started writing Kim around the same time as the Marshmallow project began as we found it wasn't suitable for our needs at that time, though it has come a long way since then.
They are very similar projects and have similar functionality, but Kim has a focus on making it relatively simple to do unusual or 'advanced' things.
For example, Kim supports polymorphism out of the box, if you have an AnimalMapper subclassed by a CatMapper and a DogMapper, passing a Cat and a Dog to AnimalMapper.many.serialize() will automatically do the right thing in a similar way to SQLAlchemy polymorphism.
We also have support for complex requirements such as nesting the same object to itself (useful when your JSON representation is nested but your DB representation is flat,) serialising multiple object fields to a single JSON field (eg full_name consisting of obj.first_name and obj.last_name,) a range of security models for marshalling nested objects and a fairly extensible roles system.
In general we've followed the philosophy "Simple things should be simple. Complex things should be possible."
I've been saddened by Marshmallow on many occasions (I have gripes with the particular way defaults/validation play together. This is true for WTForms too).
I'm excited to try out Kim. I've been very close to just writing my own serialization lib on many occasions.
It looks like your pipelines might bring a bit of sanity to it. :)
It looks like you support a few sorts of validation, but the docs aren't super clear as to what the expected validation strategy is. Could you elaborate on what that looks like?
My typical strategy I'd like to do is to just a list of functions that take the input and return a boolean as far as validation goes.
Hey that's really great to hear. (that you're keen to use Kim) WTF-Forms and Marshmallow both solve problems and they do it well but it seems like us you wanted something that offered just a bit more flexibility. That's totally the idea behind pipelines in Kim. They are like tiny little computer programmes and are really capable of anything (providing it's possible in Python of course :D )
It's great you asked this question as we noticed part of the documentation was actually broken. here's a link to a pretty basic example of adding extra validation "pipes" to a pipeline
I know the pain of searching for software to meet your requirements. But unless you have a friend you can really trust to provide informed recommendations, nobody can take this pain away for you.
If all require projects to say negative things about other people's projects while talking up their own, a lot of projects are going to distort the facts. In the end, if we don't have the ability to evaluate the software ourselves, then all we are measuring is who can shout the loudest and who is the most aggressive against other projects. Quiet projects will still be good, but now those would be overlooked even more because they aren't shouting. With this requirement you are making your life easier but you are making life harder on open source developers by forcing them to deal with unnecessary inter-project drama and to divert lots of effort into marketing that could have been put into code. That might make sense in proprietary products, but in open source this kind of demand just hurts the ecosystem.
If the pain of choosing is too much then choose something that is standardized, or the most popular thing, or what your trusted friend recommends. People will seek out the very specific projects they need. If you don't even know why you are using something, it isn't the responsibility of someone else to tell you why you are using it!
I think you're right, when actually using it for production software it's probably wise to not be a trailblazer :)
For me this wish for a comparison (that I'd love to be objective and in god spirit of course - naive?) is probably coming more from "shopping around" between projects. Or just when seeing a new thing on HN and wondering if I should investigate adding this particular thing to my toolbox.
Hey. It's a great point and something we will certainly look to add to the documentation. To be honest the docs were the major thing that held up the release of Kim. We made the mistake of leaving them until last so in the end we opted for quality over quantity to get them finished.
Why so pessimistic? Maybe when writing a blog you won't get more than a handful regular readers, but keeping it public stimulates you to talk about you, your job, and the solutions you got when encountered a problem (sure, you won't talk about how much you love your dog, I hope).
I'd also say that a well kept blog may be more important than a CV since you can actually tell how good you are in your job.
To answer the question: I used to blog with pelican, and now hugo.
I guess it came through like that unintentionally. I had a bad time dealing with procrastination back then, where I was writing up snippets and thoughts on a blog instead of working on projects that really pushed me forward in life. Tweaking html and whatnot.
I feel that most people crave attention more than they crave growing in whatever they are writing about. Maybe it all boils down to how I felt back then. These days, I read much more and write very little. It fits me at the moment, and I am better for not craving others attention and approval.
I really love debian because of its principles (and I would love to contribute), but I feel that new contributors (like me) have problems because of the many (and some old) tools and outdated and non-friendly documentation.
Also, I don't know how many contributors come and stay, but even in unstable I see some outdated packages in weeks, and also some useful software that is not packaged.