If something is open sourced, I highly prefer it if generic parts are available for everyone to use on their own projects. Keep the creative work proprietary / GPL / etc.
One reason we do open source is we don't want to perpetually reinvent the wheel. Projects last longer when they have users. And in this case of a library, your stuff is directly used by developers, further increasing the likelihood of reciprocal contributions / sharing the burden of maintenance.
I can't imagine how boasting about superiority working out in well in the end. There has to be an Aesop's Fable short story for this.
Bragging about being smarter is a standing invitation to receive passive aggressive behavior from others. People will unfairly try to find flaws, and who can blame them? They're acting innately better than their peers - while at the same time not being wise enough to be humble / modest.
I also worry it ends up having a person with potential ending up hiding behind a cryptic / abstract facade, afraid of failing when not being an instant prodigy at a new skill. Don't we will have to work our way up and build a track record of some sort?
What does being intelligent mean anyway?
Ultimately, if someone wanted to be recognized as smart, wouldn't at least some "normal IQ people?" have to understand and appreciate the value of something they synthesized/made?
> what do you have in mind actually? I am not sure since the goal here is to play the music on the device from which you access to the server.
ncmpcpp is a music client, but for the mpd music server. Not sure if LMS <-> MPD do the same things. compare ncmpcpp to mpc, but w/ ncurses + c++. It has directory-based navigation which makes it easy to move through music.
- Would prefer a permissive software license. Not much benefit to GPL. I've seen nice projects I'd have contributed / shared with where collaborative opportunity didn't happen. Too many obligations, sweeps in too many situations, and a lot of gray hairs explaining it being a net negative. I try to encourage a philosophy of YAGNI when doing open source licenses, sheerly for the sake of backward compatibility with licenses.
Don't you want your code / project to be inter-operable as possible, even with other licenses? Do you want to make development contributions streamlined as possible (even from the parade of horribles, e.g. the corporation profiting from your work with no intention of reciprocal contribution? Why impede their success? It's not your loss), or do you want potential contributor's interest to derail into a cost-benefit analysis of running afoul of GPL terms until they find an alternative?
- ncurses / ncmpcpp-like frontend. vim keybindings
- directory-based navigation. easier to navigate around, supports file structures where id3 tags aren't in place yet
Questions:
- Any info on the recommendation engine? How does it work?
It's not at that point yet. PRC does have a garrison inside HK but they're sitting still. It's possible they could go in plain clothed to collect info and provocateur to discredit the protesters. It'd cause a pretty big meltdown if they were busted doing that.
What kind of license is it? Any possibility of ISC / MIT / BSD?
Nice to see CMake!
And also nice to see an effort to make something lighter than glib.
It may be worth looking at BSD's base system in /usr/src to see code you can use as a reference, or add in a generic way. Take a look at #ifdef in ISC/MIT/BSD applications to see if you can port it in to offer portable functions.
Maybe the above is relevant / helpful / an inspiration.
We need a lite, portable glib alternative. I'm guessing it must be hard to do. I wish there was a a library where we could just pick what we want and not have to buy into an object model, which inevitably entails a lot of dependencies downstream.
Good luck with this! Look forward to watching it grow. Starred.
The interpretation I've found is after these battles (with US Carriers vs Japanese battleships in WW2) the tendency was to favor aircraft carriers and phase out battleships.
One big reason is how versatile and integral a carrier is in to a fleet. Carriers can send out scouts, attack, defend from hundreds of miles away from the carrier (where the ship is beyond the horizon, https://en.wikipedia.org/wiki/Radar_horizon).
The weakness of a battleship is the target has to be tracked, and I think the best way to do that would be aerial recon. Battleships like Yamato then had pontoon type scout planes, but nothing like a carrier.
Without a carrier accompanying it, Yamato wouldn't be able to create a defensive perimeter of fighters to ward off dive bombers. I don't think it'd be able to effectively counter a fleet with carrier in the end.
I don't think that's what they're saying though. They're talking about what the mailbox while it's in use. I didn't find anything mentioning boxes being property of the USPS, they use the term "authorized repository." When it's in use, it's still property of the private entity, but it's usage is subject to the rules of USPS. (I'm not a lawyer)
My understanding it they can remove the USPS box (looking at what postal workers said on Quora), but they wouldn't be part of the mail system anymore. I guess they could have mail forwarded to a new box, or else it'd be undeliverable.
> Writing for the majority, Associate Justice William H. Rehnquist said that no one was required to receive mail or to have a mailbox but that once a postal customer provides a box for receiving mail he implicitly agrees to abide by postal regulations on its use.
Used fire before and find it works quite well. Especially after dealing with click and having difficulties with it.
The neat thing about fire it maps a python file directly to a CLI. If you're in a pinch and want to be able to test a script easily (without having to wire in tests), this tool can help.
The docstring parsing will be very helpful. Especially since fire works by reading through a file.
> Restricting the queries is backwards. You expose should only expose the few that makes sense in the domain of your app, and optimise for those.
With exceptions:
Preventing endless recursion: Or else it'd be possible for a client to timeout with queries [1]. In graphene recursion can be checked via `info.path`.
Calculated / slow fields: Makes more sense to have dedicated objects if calculations are involved, so if they're lists/connections, there can be limits imposed for how many can be grabbed at a time.
Sometimes the only way to be sure is to only allow access to these objects if they're a direct ID lookup at the root, e.g:
Assume that if cold and uncached, it could take <1s to calculate that. Imagine if we were to have that ran multiple times:
User -> repos(first: 20) -> stats -> TotalLikesForAllIssues.
So in my case I want to make the data available, but it's not always a direct mapping to SQL. And I'm also making rules inside where the client is limited in how, and how much they can query.
- international employees (US, European countries)
- better support for employees across-states (they already do many things well in this regard)
- taxes
- general accounting
- atlas-type stuff (bank, incorporation)
- maybe a specialized account manager / team to handle the above (I guess it'd be region-based CPA/lawyers?)
Some of those are sophisticated things, but having one hub to view/manage it all from the top down would save oodles of time.
Aside: Gusto's support has been very helpful, even as an employee, when I contacted them directly they went out of their way to help me solve a payment issue.
My point is - configuration takes time. Having a dev loop to gain velocity is necessary, as is having to deploy. I believe MVP's flouting 1 week figures aren't going that far. Maybe showing it off during a presentation. I'm assuming a public demo with a backend where you can share the URL, register/login, etc.
Te output having to land somewhere. (More than half?) the time pushing dist/ files to a static host won't cut it, even for an MVP. From the beginning, the quickstart tools and workflow become a burden. Cases vary widely, here's mine:
With create-react-app, I don't want to use the included index.html / default dev-server config. I'd be using django-webpack-loader to load the webpack entrypoints. That requires webpack-bundle-tracker [1]
In my case, it'd also involve compiling via webpack, collecting static files and pushing them to S3.
The stack I suggested is opinionated for an MVP. I won't defend something so specific to my personal case.
However there's more than that at play. Let's just assume bootstrapping the basics, with a requirement there's a backend and it has to be deployed:
1. If there's a requirement to have a backend connection and deploy the mvp, that rules out create-react-app / @vue/cli in most cases since it'd be too custom. The app would need to be ejected. But even further, the ejected app is overengineered.
It takes 1-2 days just to get a frontend setup working the way I want. What create-react-app / @vue/cli gives out of the box isn't sufficient if you're connecting to a backend.
I like graphql in the backend and having it generate a schema file, and getting typescript typings from that, so all the data structures align nicely.
Add pushing to heroku / some cloud service via fabric, that'd easily put me at 1 week.
It's after the first week stuff really comes together. Then there's a reliable hot reload loop, scripts, familiar stuff you're used to is prepped.
I don't like the 1 week thing because I think you'd be stuck inside a framework/starter kit that'd hold down what you want to build. I think a month is minimum if you wanted to impress and get your idea across.
Don't give coding quizzes if they can provide better evidence of their ability.
It's unfair in the least, rude at the worst to pigeon-hole "senior" programmers into scenarios / pop quizzes.
Let them show off recent personal projects. They'll probably have no problem spending a weekend hacking on something they're passionate about.
Be a serious employer:
Convince the best programmers (whatever that means) why they should reorganize their life around your business:
- Pension plans / job security are nice. It's a good motivator to know that there will be an annuity when they're 60 / 65 and would rather spend time with their family.
- Union contract (or something comparable) or a labor system with robust employee rights and unemployment insurance. It's pretty unfair in the US with at-will employment.
- Have strong financials. Be a business that'll be around in 10 years. Can your business keep paying employees if it's in the red for a year?
If you don't offer the above: Why feel deserving of the best?
I'm being facetious on the above points: It's tech, it's a fast cycle and inherently unstable. But when orgs talk about hiring - it irks me to see the entitlement employers have when they have little investment in the welfare of employees as persons (and families)
There's a lack of financial incentive to build TUI apps. It's a niche. It's awesome for power users: no lag, all keyboard driven, raw structured data. But businesses buy slack / trello / salesforce for swathes of people. That sort of thing doesn't happen if the following is simply limited to programmers / power users (and a cross section of those at that)
I wrote a book on tmux that briefly touches terminal stuff. I still get confused when terminals are miscolored and emit junk characters. There's a lot more going on behind a terminal than meets the eye: https://en.wikipedia.org/wiki/POSIX_terminal_interface#Gener...
What I'd like to see (2D games): Permissively licensed, widget / sprite tooling, handling of rotation, blitter, canvas resizing, scaling.
Anecdote: I made a request for a Zelda clone to make their code available via a commercial-friendly license here: https://github.com/solarus-games/solarus/issues/826
Look at this, well-maintained C++ bits and pieces wrapping around SDL2, that could easily apply to more than just this game:
https://github.com/solarus-games/solarus/tree/dev/src/core
https://github.com/solarus-games/solarus/tree/dev/src/graphi...
If something is open sourced, I highly prefer it if generic parts are available for everyone to use on their own projects. Keep the creative work proprietary / GPL / etc.
One reason we do open source is we don't want to perpetually reinvent the wheel. Projects last longer when they have users. And in this case of a library, your stuff is directly used by developers, further increasing the likelihood of reciprocal contributions / sharing the burden of maintenance.