Ask HN: Do you have any projects you'd like input or collaboration on?
I'm sure some of you have projects you've been working on alone and wouldn't mind some input on. Maybe you're good at algorithms, but suck at UI or the inverse? Maybe you'd just like some constructive criticism, hints or tips on how to do something?
Maybe HN can put their collective heads together during this quarantine and work together :)
13 comments
[ 3.4 ms ] story [ 36.3 ms ] threadHopefully somebody will be able to give better feedback.
I wouldn’t mind someone to look at my horribly hacked together python helper scripts (python2: https://bitbucket.org/koalephant/shell-script-library/src/de..., python3: https://bitbucket.org/koalephant/shell-script-library/src/de...)
I do not write a lot of python so you can’t hurt my feelings telling me how bad they are. If anyone feels really bored and wants to improve them, there’s unit tests that should help (technically the unit tests cover the shell functions that call each helper script) in the repo.
If anyone feels ridiculously bored and wants to port one to ruby or Perl (or heck even awk if you’re feeling particularly adventurous) I’ll be forever grateful.
I had a quick look and here are my remarks:
- with the [six] library, there's no need to maintain two versions
- parsing script args yourself isn't necessary either thanks to tools like, [argparse] (in the stdlib), [click], [docopt]
- not quite sure why you use the RawCongigParser, but it seems like you're modifying the behavior thereof. It might be advisable to subclass it instead
- a little documentation wouldn't hurt
- it's not entirely clear why the code is doing what it's doing
- not sure what the goal of this is
Haven't run it through a linter, but I like the descriptive variable names and methods and the spacing. The lack of a argument parser has led you to convoluted code however: 5 levels of ifs aren't easy to read.
[argparse]: https://docs.python.org/3/library/argparse.html
[click]: https://pypi.org/project/click8/
[docopt]: https://pypi.org/project/docopt/
[six]: https://pypi.org/project/six/
To answer some of your questions: the goal of this (the concept rather than just this python implementation) is to read keys and values out of 'ini' formatted files from shell, by detecting which other languages can run on the machine (so far, python2, python3, php with DBA support, and php without DBA support), but Python's idea of what constitutes a valid 'ini' file is more restrictive than other languages, in that it doesn't allow for values before the first section heading (the parts in square brackets). So that's why it inserts a 'fake' section header and passes the StringIO object rather than just the file itself.
I'll look into argparse - being in the stdlib is a must - the only reason this (or it's counterpart in php) exists is because so far I've found no practical/reliable way to reliably read/write ini files via pure shell. Having to package up extra libs, or require a non-standard lib would defeat the purpose.
I wonder if that's going to be the situation with 'six' - is it a runtime library, or more of a 'build' tool, to transpile from 3 to 2?
I honestly don't remember why I ended up using the RawConfigParser rather than just ConfigParser - maybe one of the options for ConfigParser (e.g. disabling interpolation), wasn't available in earlier 3.x releases. I'll try this again when looking at the above points.
Thanks for your input, it's very much appreciated!
It's a runtime library. [2to3] is in the stdlib and transpiles.
> To answer some of your questions:
That whole paragraph could be put at the top of the file in a triple-quote. It explains what the file is for pretty nicely. If you end up using argparse it could be in the description :)
I'm glad I could help somehow. Have a nice easter!
[2to3]: https://docs.python.org/3/library/2to3.html
You're picking the environment you deem necessary and affordable, and our solution will automatically create appropriate build + deployment scripts for you. We promise no lock-in, generated scripts are downloadable and executable on-premises.
Our working MVP currently supports Java/Gradle based backends and angular / react based frontends. Supported databases are currently PostgreSQL. Supported cloud platforms are currently AWS, Azure to come next.
Roadmap:
* Azure support
* Google cloud support
* .net core backend support
Our own platform runs using our own product. We're searching for a select few alpha customers (lifetime free, incl. support).
If you're interested post a public comment here. No public details will be provided. The planned public alpha launch date will be around September 2020.
How would you describe this in under 5 minutes to a interested friend or family member / layman at a social gathering? If you have the time, make a video, put it on peertube and link to it in your readme. It'll take a few hours or so to do it right, but it might help.
A somewhat superficial way to describe the application is perhaps to call it a more semantic wiki; for example, the application allows you to establish semantically meaningful relations between topics (i.e., defining not only the type of relationship but also what role each topic plays within the context of the relationship). There is much more to the application than just that, but it is an example of how the application allows you to model/express a knowledge domain.