hex13

"Error establishing a database connection" :/

some options like Apocalypticism seem normal, without any special effects.

I think it goes beyond subjective likes/dislikes. I personally like reinventing the wheel, you personally believe in ecosystem, these are just our beliefs.

But I think in the long run everything depends on exact project rather on our wishful thinking.

I had experiences when use of library was much better solution than own baked one, but I also had experiences where none of the libraries I had found were quite fitted for the project and many times I just had to throw library and write something from scratch in simple way.

> reusable libs are tested by the whole community.

reusable libs are often FOR the whole community and not for YOUR project. Ofc sometimes you need exactly what rest of community needs, but sometimes not.

Of course. Web applications are bigger and bigger, and quite often you have some hierarchical data structure in JSON (usually in form of tree, but tree is kind of graph anyway).

You have to deal with these kind of structures anyway. You have to be able to render such data as hierarchy of components, you have to be able to get some information from it, to transform it, to update it.

Tree traversal is almost as common in front-end world as using .map, .filter or .reduce, I think (and using `reduce` also can seem hard on beginning, but it's quite useful).

I agree that sometimes the best solution is to use existing library, but I can't agree that traversing graphs is "too complex to implement from scratch in a timely fashion".

This very statement reminds me of famous "why can't programmers program" article: https://blog.codinghorror.com/why-cant-programmers-program/

Programming needs some technical skill anyway. And learning "how to use library X" often takes more time than learning "how to implement algorithm X". Libraries are often bloated, bugged, hard to debug or have terrible API. In these moments basic programming skill set is very useful.

Maybe all these "I'm \d+ years old, and I like this song" before each old* song were written by bots. This would explain a lot.

*old song, according to Youtube comments is every song recorded before 2016 AD.

> the problem stated is often not the problem faced.

100% true! So many times I was assigned to the task in issue tracker, where requirements was written, estimation was made, but after I sat and tried to solve given problem, it turned out that 80% of issue description was false - real problem was totally different than it was written in task.

What seemed right on planning meeting, turned out to be quite false in the process.

But quite often managers/product owners etc. don't understand this. They often believe 100% in planning ahead and issue tracker/backlog descriptions... And when something is going off the track (like it sometimes does - when problem needs extra time for thinking through) they aren't so glad because thinking and design process was not budgeted in issue tracker (even if it could lead to the better design on the long run).

Yeah. Many of these tips are still valid in new Chrome* (despite the fact the article is from 2006 and about Opera) so I think this article can be still helpful (ofc I would verify every tip by making actual benchmarks before I would follow it).

*I checked some tips in Chrome Dev Tools, and most of them was still relevant.

I think support for butterflies is what turns a text editor into a code editor (xkcd#378) XD

It's worth noting that original oblique strategies were invented by Brian Eno and Peter Schmidt in '70s: https://en.wikipedia.org/wiki/Oblique_Strategies

Think like a tree - e.g. NoSQL databases which allow for keeping hierarchical objects in database (in contrast to relational databases like MySQL).

Think like a stack - e.g. take this from Redux documentation:

"In a more complex app, you're going to want different entities to reference each other. We suggest that you keep your state as normalized as possible, without any nesting. Keep every entity in an object stored with an ID as a key, and use IDs to reference it from other entities, or lists. Think of the app's state as a database." http://redux.js.org/docs/basics/Reducers.html#note-on-relati...

TL;DR Redux docs are telling you "Think like a stack: zoom in to the book-keeping details and ignore the structure."

Why didn't you just pass one element list with your class with it, for example:

  class MyClass:
     pass

  class_list = [MyClass]
  third_party_function(class_list)
  # or just 
  third_party_function([MyClass])

?

creating some simple wrapper for third party function, e.g.

  def wrapper(C):
     third_party_function([C])

could also be much simpler solution :)

But it's maybe off topic.

"Being a new kid out of school, I felt too young to call bullshit but intuitively, I felt the metric was flawed."

You should have said that to the team. Especially that if anything goes wrong in project, usually it's new person on the board / junior programmer that gets the blame.

Besides not telling that was just not honest to the team. I think we should all learn from each other, no regard with the job title.

They gave him shitty work that nobody wanted to do, and you are surprised that guy had no motivation for do it?

> work that wasn't too complicated

"complicated" is subjective. There are many talents and somebody could be better in for example JavaScript (and not HTML/CSS).

CSS is not only selecting elements (like JS is not only "defining functions"). Creating complex CSS layout can be hard the same way complex JavaScript system is.

I think in 2016 people most developers have disk space for install additional 100 or more megabytes for code editor (unless you're working on low end with very small disk size, but If you do, you would have more problems than freeing 100 megabytes of space)

yeah, predefined actions for often used features is good (if you assure that it would be possible to add some custom JS action if needed), but frankly I think this project could be better (I mean, really better, it would be killer app), if you would go further and made visual editor for that. Some sort of modern WYSIWYG. Nobody wants to edit manually plain JSON files... But if editor could let you to make apps without code and generate/modify these JSONs for you, it would be nice.

I think data-driven approach is huge win for that. It's all data after all.

What is the problem? Creating visual editor is hard. Idea is obvious, but implementation, ux etc. is hard (I see sometimes visual editors for apps and most of it are sh*t).

Been there, done that. When I coded games, I made some simple JSON based file format and almost whole game was in form of JSON. I even implemented conditional and loops in JSON.

But It can easy lead to inner platform effect. Not needed complexity. And in JSON you can't write JS code (needed for e.g. event handlers).

So I switched to JS. Still data-driven approach (simple hierarchical objects with data), but with power of JS (and if you're use Babel, you could use JSX for your DSL).

So: I don't think JSON is best format for what you try to achieve. It's just so limited.

Besides what is added value of Jasonette? When I look on Jasonette I have feeling that it's just reinvents ReactJS but in JSON not JSX. Not sure if there is much profit with JSON format alone.

It's correct. I've noticed that when I work in a team I work with maybe 10% of my solo efficiency. Just because of this whole team work bullshit and because of legacy code (it takes me often more time to understand how code written by someone works than it would take to write such code from scratch).

It looks for me that despite what author wrote, he WAS indeed in exploratory phase: `So now we have a sequencer device, how do we get events from it? Can we do it in the main loop? Turns out it probably doesn't integrate too well with Qt, (...)`

`My initial thought was making a grid of spinners,(...) but then I realized that there isn't an easy way to make headlines in Qt's grid. (...) So after some searching, I found out that it would be better to have a tree view(...)`

And many similar things. Exploration and technical spikes - nothing wrong with that but author wrote: ` It's pretty common to do so if you're in an exploratory phase, but in this case, I had a pretty good idea of what I wanted to do right from the start, and that plan seemed to work. `

and then he contradicted himself writing about various difficulties and explorations... (I don't see anything wrong with that, absolutely. I think that exploratory phase is essential to good design).

in HTML5 would be sufficient: const $ = document.querySelectorAll.bind(document);

(but it would be only pseudo jQuery, the way you can have pseudo React just by using functions and ES6 template strings https://jsfiddle.net/vug86rn0/ )

I know, but it's too verbose for me. BTW there is a discussion about this: https://github.com/facebook/jsx/issues/23

I wish it could be possible to write this:

const animal = "cat"; <Component {animal} /> equivalent to: <Component animal={animal} />

Don't ask me. They're exaggerating ofc but I sometimes hear that somebody in his twenties feels old.

how old? 60+? 50+? 40+? 30+? 20+? (I'm serious, sometimes even 25 year old devs feel old).

There will be.

Maybe I will port my Atom plugin ( https://atom.io/packages/atom-lupa ) to VSCode or maybe I'll write from scratch whole thing.

I don't know when exactly though (now I'm making something bigger than that and it takes time).

It depends. In many cases you would be right, in many other cases you wouldn't.

It depends on many factors:

- what is the problem? (some problems are really hard, some problems are trivial and just seem hard)

- is developer experienced enough to build own solution?

- are existing solutions good or badly written?(I often refrained from using existing solution when I looked on bloated code in it).

- is solution suitable to project? ("too much bundle size", "doesn't support X", "not too configurable", "too slow", "too hard to use").

etc.

I begin to think that nowadays websites are just designed for "zooming in" in mind (very small fonts, too many space etc.).

So maybe we shouldn't complain. These websites are just meant to be zoomed.

Although some web developers are cruel and block zoom with meta tag (I never understood why some developers did that, maybe for trolling people with poor sight?).

I did debug NodeJS backend (multiplayer games) with Electron.

It was very cool because I was able to see internal server state on simple HTML dashboard I made (for example I was able to see map with player positions or some important game variables etc.).

And I made some controls(buttons etc.) to dynamically change state on backend (for purpose of tweaking/experimenting/etc.).

So it was like turbo-debugging :)