Fannon

With RDBMS you have to design the schema first, with NoSQL you don't need to. This is nice when you're dealing with very diverse data (or data you don't even know how it'll look like) or are prototyping. One thing I like about this: You can store your data as it is, you don't have to fit it into your model / world view. You can make sense of it later.

At some point you'll probably have to deal with schema anyway. If this comes at a later stage, you'll have to deal with a lot of diversity and inconsistency on potentially many points. This can become much more painful and time consuming than having dealt with it from the beginning.

If you're thinking about NoSQL as something like a simpler, modern SQL alternative, you're probably having a faster start and a lot of problems in the long run.

Scalability is something, NoSQL databases have for them, definately.

Ok, you're right, and I wasn't completely sure myself when writing this sentence. There are cases (integration of web services, the overall architecture) when some difficulties from the web architecture swap over to the backend.

But wouldn't you have a similar problem if you try to integrate something other than web services, too?

Yes, the web is a very messy place. Maybe a kind of wild west of programming practices?

But it's also a place where you can do a lot of things that no one has thought before. There are not many rules and a wide diversity of approaches. The web platform never had many of those approaches (e.g. complex web applications) in mind when it was created. It works somehow, anyhow. It's chaotic, yes, but also flexible and full of freedom.

To stay sane in this world, you have to voluntarily and deliberatly (!) reduce this freedom and create yourself some small sane pockets that you understand well enough and feel comfortable with. This can be done by increasing the abstraction level and restricting feature sets (e.g. ESlint), using Frameworks (React, Bootstrap, ...) and transpilers (TypeScript, Babel, Sass). Note that you're loosing freedom here and you're buing into other peoples understanding how a sane place of web programming should look like. In the Web there are a lot of ways to do things, there's no monoculture! And if you don't like the existing ways, roll out your own (though I wish people would be more careful / sceptical with this attitude).

And there's the backend. You've got all choices of programming languages and frameworks there. If you're making a mess of you're backend, you really can't blame the web for it.

For someone without much web experience, this process of choosing frameworks, workflows, toolsets just to get to one (of many!) sane programming experience is surely daunting. You have to choose and configure your envirionment yourself first, just to get started. You really need someone experienced to set this up and understand most of its implications. If you're having so bad experiences with your current web project, maybe some bad decisions were made regarding this. Or too much freedom (and therefore chaos) was left in place and got out of hand.

If you don't have the experience to make those decisions, you could just start with one approach that is pupular right now. I guess on hacker news this would be something like React, Babel, etc.. There are a lot of tutorials out there to put this all together.

Basically any database should do for this usecase. A simple key-value store probably best. I'd aim for keeping the technological complexity as low as possible.

What is the simplest tool to do the job? Or maybe better yet: Use something that's already (or will be), in your technology stack to avoid having one more thing in it.

Thanks for sharing! I was looking for something like this the last weeks. I especially like that it doesn't use a DSL, but JavaScript itself, so it's easier to debug and inspect.

Is there any way to generate a final parser file, nevertheless? Or somehow bundle it up?

We use MediaWiki + SMW / Semantic Forms. This allows to define a data model and forms which makes it easy for user to add / write to the wiki in a structured way - and without sitting before a blank page. For free text, the new Visual Editor works also rather well, though it's not easy to setup.

The structured information can also be queried, visualized, exported to various data formets etc.

To document software projects, I really like to write *executable documentation". E.g. I'm using JSON Schema a lot to define my expected data structures and contracts between modules.

Then I write a small program that automatically generates the technical documentation based for me. Humans can still add/annotate to the documentation because it's a wiki (and I can separate between auto-generated and human-generated rather easily, because of queries).

So far, I really like this approach as it has the automation of doc generators, the flexibility of wikis. Most of the information is stored/accessible as data / API. The downside of this appraoch is, that this platform takes some time and knowledge to setup and model the data structure / forms. Without those, corporate wikis usually seem to die the "one man show" death you described

Great idea!

I would love if this would be something like a independend, modular micro-services architecture you can easily and selectively deploy within your own network. Docker might be a good way to manage it.

Looks great! I've noticed one thing that bugs me immediatly, though: The animations of the navbar dropdowns are way to bouncy / slow.

Since dashboards are work and productivity oriented, I personally prefer as little animation as possible, since they (in this case unnecessarily) delay the time to navigate the menu.

Nothing against animations in general. They are nice to hide or ease loading times, etc.

This problem also applies to MediaWiki. They decided to internationalize pretty much everything, too. Not only functions are translated; the functionality of some URL parts also depends on the language - and you'll get a lot of duplicates when more languages are enabled.

I have found this bash function a while ago. It doesn't save all the steps, but it shouldn't be too difficult to add them, too.

https://gist.github.com/Fannon/41b0a6104435943cd826

alias ip="curl icanhazip.com" # Your public IP address

alias diskspace="du -S | sort -n -r |less"

alias pyserver='python -m SimpleHTTPServer'

alias phpserver='php -S localhost:8000'

alias phplog='tail -f /var/log/apache2/error.log'

Looks very nice!

Is there something similar for Windows? Or for the linux shell?

I also don't think that the problem is the rise of mobile devices here.

My perception is that Wikipedia has developed a culture that where new people are really discouraged from starting and contributing. The problem is both social and technological.

And while the MediaWiki software is open source, it forms a rather closed / restricted sub-area of open source software. They reinvent alot within their community. I'd be very happy if they did some steps like Drupal 8, integrating part of the Symfony 2 Framework.

Nevertheless, Wikipedia / MediaWiki are still very powerful and I don't see any viable alternative to them as of now. It was / is a highly successful project. Not many software projects grow so old and are still relevant.

Censorship is when the content has to be pre-approved by an authority in order to be published at all. If content is removed after it has been published (because it violates some agreements / ethics), that's moderation or "legal-stuff".

Of course, moderation can be misused to a point where it's almost effectively cencorship. But IMHO, the order matters here.

There are some real and difficult problems the Semantic Web tries to solve, like finding a common language to talk about things and automate information discovery, merging and interpretation.

This may become even more relevant with trends like the IoT (how smart can that be if every company uses its own home-bred standards and the devices can't automatically understand (and react to) each other? This also applies to Robotics / AI.

I'm really not sure the Semantic Web is on a good road there, but they are actually thinking about those hard (and interesting) problems.

There is at least one project where I can see true value, even today: Schema.org (http://schema.org/). And if you're only creating semantic annotations, it really isn't that difficult. Sadly, to smartly combine and make real value out of Semantic Web Data you probably need to be a BIG company like Google.

http://schema.org/ is probably the best choice to go with already established standards. I think there are (even today) some SEO benefits here and for the future maybe some more exciting things.

Just yesterday I've deeply regretted installing Python3, because some build scripts (atom-shell, a fairly new project) failed badly. Things like that happend regularly. Right now I can only install both Python2 and Python3 and adjust my PATH variables, depending on what I want to do.

The Python community beeing so split and "backward-oriented" is really the main reason why I wouldn't consider Python, though I like many aspects of the language.

While I agree that multi-tasking is a bad idea for productivity, three monitors don't necessarely lead to multi-tasking.

It really depends on how much screen space you need to efficiently do one task. Having three monitors myself, I mostly use two of them, sometimes one or sometimes all three, depending on the task. So you can still minify distraction.

And there are definately tasks where three monitors come in handy and save me a lot of window switching / aligning.

FYI: JSON-LD is already W3C standardized and may be interesting regarding APIs, especially in the area m2m:

See http://de.slideshare.net/lanthaler/building-next-generation-...

But my "fear" is that it will all get to complicated, too. Currently I really like to work with JSON Schema (http://json-schema.org/), because it's simple and extensible.

A great title would have been: The Guts of Git.

Oh no, someone is thinking the obvious! ;)

It may be true that thinking your code through takes a LOT longer than actually writing it. But: Beeing able to put a thought / idea (once it's there) to code very fast is helpful. At least I can't hold an complex idea in my head forever. If someone is really good at 10 finger writing, he doesn't have to put thought / focus in the writing process itself. That frees him up for the thinking process. Writing documentation is important too, and here speed can be helpful, too.

And 60wpm isn't that much. My impression is that some young people write that on their smartphone ;) (though definately you couldn't call that high accuracy)

Paperwork doesn't use its own cloud storage. You can host it either locally or at your own server. No problem using encryption, VPN tunneling etc. here.

The fact that it's not a true cloud service could be seen as a downside. Your data is only stored at one server without failsave mechanisms. And you're responsible on your own regarding the data.

Thanks- this is really great! Each time I've learned a new language, I've created a file / collection of files like this - as a personal summary and for use as a cheatsheet. (Can recommend this definitely!)

But this is much more comprehensive.

I can see the problems of the current situation, too. I guess everyone involved does. But what's a viable alternative?

I have seen a few project that were completely build on its own, without dependencies on external libraries. Not only that those projects turn out to be even less modular (because it's not enforced by a package manager / module system), but the chances that code gets unmaintained are also rather high, since developer time is often rare.

An interesting point is releasing the software. No problem with putting it on GitHub, but if projects are commited to official registries like NPM or Bower, the author should really put some commitment into it. Currently it gets ever more complicated to find good quality libraries, becoming a needle in haystack problem. So a "release ethic" wouldn't be too bad.

babun looks really interesting. So far I've worked with PortableGit + ConEmu which works quite fine - just updating is not the nicest experience.

What NPM can't do is the async workflow of Grunt watch (or serve) and dynamically trigger specific (sub)processes in real-time. Turns out, this is the main way I'm using Grunt.

Also some plugins are complicated (or dynamically) to configure. His examples were very simple, he could just put it into a batchfile aswell.

The more I think about it, I dislike the idea of WYSIWYG editors. Not that I would force normal users into writing markup, thats even worse.

But in order to deal with browser inconsistencies and potential new and interesting features, the idea of WYSIWYM (What You See Is What You Mean) looks much more promising to me. The most important thing is, that the editor / workflows disallows users from making mistakes and get the result they wanted to. Regular WYSIWYG editors give too much freedom, resulting in mixed results and often confusion.

Even for simple tables, it's hard to edit a table if it has to look exactly like it should after editing. If you allow the editing experience to be different from the reading experience, you could provide additional hints and tools in the interface.

My personal experience is that often users prefer an even stricter way, of entering content through very strict and validating forms. The visual output can then be created from "raw" data. Which is not only consistent then, but can also be altered.

Of course there area areas where WYSIWYG is just fine, but then I'd prefer more "seamless" editors like http://www.aloha-editor.org/

I had to try to believe it.

Well, there are reasons and it's getting more common. In fact most modern browsers, even on a smartphone, may have more computing power than a server if you consider that the client has only to serve itself and the good performance of modern JavaScript engines. And having to do a lot of networking with a server slows a lot too, since network is one of the slowest and unreliable parts of an app.

So your answer sounds more like an excuse than a solution to me, sorry.