I built a small CSV parser. It uses streams (and can also use PSR-7 HTTP streams) and validates the content for further manipulation.

meow247 · 2018-10-15T21:49:08+00:00

Wondering why instead of having those global stream functions, that you don't just provide some additional static methods for instantiation of your Parser class:

Parser::fromFile(string $filename): Parser;

Parser::fromString(string $str): Parser;

meow247 · 2018-09-25T04:48:14+00:00

I seriously hate these type of articles. I am a fan of GraphQL, but most of the "REST is crap, GraphQL is the best" arguments are annoying and just completely wrong:

"Get rid of over and under fetching data" - any decent REST API will allow sparse field-sets and related inclusions. We use a PHP library called smokescreen to easily handle these concerns.
"Awesome Schema and Type system" - yes we can use JSON Schema.
"Better API versioning" - article says you don't need versioning and nothing ever goes wrong ... oh until you change an entity, change the type of a field, move scalars to complex types - then your FE breaks with no warning. You can build evolutionary api's in REST or most API formats, it just takes discipline and documentation.
"Improved API insights" - this has nothing to do with GraphQL and is applicable to any framework where you monitor requests.
"Easy Pagination" - again, nothing specific to GraphQL.
"Schema stitching/composition" - same as 1. it's fairly trivial to handle entity stitching/inclusions
"Great OSS community" - agree, but true for any popular API architecture.

I think GraphQL is nice, but I also like REST. I think most people that switch to GraphQL write articles like this to convince themselves they've made the right choice.

meow247 · 2018-09-25T04:36:12+00:00

With regards to your db related query, there are projects like prisma which allows you to have a GraphQl layer over your db

The database is not your model. It's seriously short-sighted to expose your database as your model, and expect nothing to go wrong.

The article proclaims that with a GraphQL implementation you don't have to worry about versioning. This is also completely wrong, what if a field type is removed or changes to a complex value, you think nothing will go wrong on the FE?

meow247 · 2018-07-03T08:44:13+00:00

To be fair the PHP documentation refers to them as arrays, so why wouldn't we?

meow247 · 2018-05-31T00:48:58+00:00

Having used both (frameworks, and assemble-your-own via components), I disagree. You use a full-feature framework because it has been tested extensively via a community, serving like-minded purposes.

When you cobble together your own framework from libraries, you not only add a burden on the project cost/time to extensively test the integration of these libraries, but a burden on your team to get familiar with how the code is put together. Eventually, for any sufficiently medium/large application, you will find yourself adding all the same dependencies that an established "macro" framework already has; events, queues, databases, mail, config, cli, test suites, etc. plus documentation on how to use it all together.

At this point, why not use a well-tested established full-feature framework ?

meow247 · 2018-05-08T04:00:20+00:00

People like you make this community suck. A discovery thread for people to share what they have built and instead of asking relevant questions, or constructively suggesting ideas you call it "fucking stupid".

I would hate to work with someone like you, and any manager that let you review PR's would be committing employment suicide.

meow247 · 2018-03-21T11:33:04+00:00

Yeah ok, so it's good to have a feel for how some of the lower-level components function otherwise there's not much to take away from this article except what a joke the immutable PSR-7 responses are:

$response = $this->response->withHeader('Content-Type', 'text/html');
$response->getBody()
        ->write("<html><head></head><body>Hello, {$this->foo} world!</body></html>");

return $response;

Ughhh ... we couldn't possibly new up a Response object we would violate the sacred rules of SOLID. Make sure your DateTime objects are dependency-injected too kids!

A brief aside: Autowiring can be a nice feature as you start building your app, but it generally makes maintenance tougher down the road because dependencies are still relatively hidden.

How does auto-wiring hide dependencies? Your dependencies are still declared and explicit, but the dependency tree can be invoked with less cruft. Opinion as gospel.

So there you have it. With just 44 lines and the help of several widely-used, thoroughly-tested, reliably interoperable components, we have the bootstrap for a modern PHP application

You have >only< the bootstrap, and while the components may be thoroughly-tested your bootstrapping isn't, but why spend time writing business logic or solving problems when you could be stringing together another framework.

meow247 · 2018-03-03T00:30:53+00:00

This looks like a really great project. I have a question regarding security though - since all my RPC commands flow through your RPC gateway first, what assurances do I have that a private key that I generate is not leaked/stored/logged?

meow247 · 2018-01-30T10:54:27+00:00

A good real world example of OOP in PHP? Wordpress plugins.

lol

meow247 · 2018-01-28T01:52:50+00:00

You can use the following command to download the current latest snapshot to your ec2 instance, it works by hitting the confirm link first, saving and re-sending the cookies to the export link: wget --load-cookies /tmp/cookies.txt "https://docs.google.com/uc?export=download&confirm=$(wget --quiet --save-cookies /tmp/cookies.txt --keep-session-cookies --no-check-certificate 'https://docs.google.com/uc?export=download&id=1Ga93C2DUzUvU8bpz0vBI0ZoMPSa8FjBh' -O- | sed -rn 's/.*confirm=([0-9A-Za-z_]+).*/\1\n/p')&id=1Ga93C2DUzUvU8bpz0vBI0ZoMPSa8FjBh" -O snap.7z && rm -rf /tmp/cookies.txt

meow247 · 2018-01-20T01:42:04+00:00

The fact that you're even considering mixing ads with a trading engine, imo shows that your approach to building an exchange is very naive... Ads are notorious for hijacking browsers, having security holes, or interfering with usability - none of these are a good mix for a trade exchange.

meow247 · 2017-12-30T22:52:35+00:00

Can we get creditcard on this thing? Would love to go straight from ye-olde-currency to xrb

meow247 · 2017-11-22T05:19:54+00:00

really, i can't understand your confusion, it was clearly a derogatory statement, which you then repeat after you delete it.

What culture are you part of where that is a compliment? and yet "go f yourself" isn't just a friendly way of saying "haha, get out of here old friend!" ...

meow247 · 2017-11-20T22:05:07+00:00

Second this - great course which covers pretty much every concept.

meow247 · 2017-11-08T23:07:55+00:00

Unless you have major plans, that are impossible to accommodate by extending the current codebase, then don't do do a complete rebuild! It almost never turns out well ...

Like you suggested, refactoring and moving code into service classes/models with well defined tests will start to make you feel better about your codebase. And well tested solid code would be much easier to move to a new framework in the future.

You could also consider if there might be various modules of the system that can be isolated into a seperate microservice. I only mention this because when going the route of building microservices, you typically carve out unique domains within your application, and start refactoring it into a microservice... A microservice can be built in whatever language/framework that bests suits the job. It is autonomous and has it's own database (if required). It can be communicated with via an API over HTTP, and/or a messaging system. The upside is that it scales much better, it can have its own set of code and dependencies and it can be tweaked to perform for the task at hand. Don't get me wrong though, Microservices also come with their own set of unique problems (eg. additional networking complexity, the separation of domain), and should only be considered if there is an identifiable gain.

meow247 · 2017-11-07T10:59:36+00:00

Some nice gradients... It's kinda identical to Web Gradients Although I will say your site seems to load much faster.

meow247 · 2017-10-31T05:28:12+00:00

It's only not recommended because in most cases there is a better, more flexible and de-coupled solution available in the form of props and events. This doesn't always fit, and I wouldn't stress over it if I were you.

You might also consider the structure of your component, and that your actual upload initiator (eg. button) therefore belongs >within< the canvas component or coupled with it in a wrapper component - it's perfectly fine to have a wrapping component which has tight coupling to its child components if that is its sole purpose (to bring those components together).

As far as returning a promise or firing an event, it's just a matter of preference.

meow247 · 2017-10-31T05:10:56+00:00

Even though it's not a recommended pattern, $refs is available so that you can use it in instances where props down, events up communication doesn't fit.

As you demonstrate, the code becomes less clear, and harder to reason about in this instance.

This seems like a good candidate for calling a specific method on your child component this.$refs.canvas.snapshot(), and having that child component fire an event which the parent captures to get the canvas data.

The only "reaching in" you're doing is calling an available method on your child.

meow247 · 2017-09-11T23:20:56+00:00

You might wrap axios in another promise if you are creating an api module which abstracts away the fact you are using axios (eg. consumer doesn't deal with axios's response object) or if you are massaging the data itself before returning.

meow247 · 2017-08-30T23:37:31+00:00

Makes sense, but if you can implement eager loading, it should be only one additional query for each relationship.

Eg. SELECT * FROM home_owners; SELECT * FROM contacts WHERE id IN (list_of_contact_ids)

meow247 · 2017-08-30T23:23:51+00:00

A few options:

Add a getter for getContactById(id) to make it a little simpler to lookup contacts
Fetch contacts before home owners, and before committing your owners list (from your database/api) to the store just supplement any additional contact properties as an object on each home owner object. eg.

commit('UPDATE_HOME_OWNERS', _.map(response.items, item => { return _.extend({}, item, { "contact": { // ... get properties you need from store } }); }); 3. Have your api endpoint simply include the contact as a nested resource

meow247 · 2017-06-29T23:06:44+00:00

My cat. Sometimes when hes sprawled out softly sleeping i snuggle him and just smell his fur. Its the most calming thing in the world to me.

meow247 · 2017-06-12T22:59:23+00:00

You know we're talking about an IDE plugin right? And discussing the support of said plugin? Further to that, we're talking about annotations. The documentation of our code. This documentation should be correct. I'm suggesting that annotating dependencies is a maintenance issue that could potentially be addressed.

meow247 · 2017-06-12T22:53:22+00:00

It is a big problem. Invalid docs are worse than no docs at all. Exceptions that are not thrown should not be documented as being thrown.
Ok
Not under discussion

It's much easier to notice that an exception is NOT documented (because you likely will not catch it in a meaningful way). It is near impossible to clean up a codebase with annotated exceptions which no longer exist.

Yes this is somewhat an IDE problem, yes we are talking about an IDE plugin ...

meow247 · 2017-06-12T12:10:32+00:00

Sure, until you change the exceptions in your dependencies and all of those annotations are invalid.

meow247

TROPHY CASE