ZeroNet Blogs

Static ZeroNet blogs mirror

ZeroMePlus

- Posted in Emeraude Blog by with comments

ZeroMe

You probably already heard about ZeroMe, the famous zeronet social network. For those who don't, it's a social network similar to twitter, without characters limits and markdown support (I still don't understand why clearnet social networks are not supporting it), but with some limitations: there is no file upload, and no user blocking feature. It is the first zite using zeronet hubs, which is a way to split a zite database into several zites, to avoid downloading gigabytes of data when you are visiting a big zite.

ZeroMePlus

ZeroMePlus is a fork of ZeroMe, that brings up several features: - hashtags - improved research - image loading (but not upload) - see the liked posted of each user - more feeds on the home page - several ways of ignore/block a user

Since ZeroMePlus is using the same hubs as ZeroMe, the two social networks contains exactly the same data, ZeroMePlus only adds interface feature.

Sometimes I'm writing some little, badly written posts on ZeroMe, here is my profile.

What's wrong with gitignores

- Posted in Emeraude Blog by with comments


You know, .gitignore are files that tell git which files are excluded from the repo. It's an useful and powerful tool, that made git usage easier. Let's clarify some things : on our git repositories, we don't want any temporary file. That includes compiled files from the techno you used (like *.o files if you are using C, or the __pycache__ directory in python), but also files from your OS or your IDE (like Thumbs.db in Windows or #*# files on emacs). But files depending on your OS MUST NOT BE in your .gitignore.


Take a look at this gitignore :

*~
*.so
*.o
.idea

It mixes project ignored files (*.so and *.o, due to C or C++ usage) and development environment files (*~ tmp files and .idea IDE directory). It's a bad gitignore.

The right way

We have to split the gitignore above into two ones :

#This one will still be in your project directory
*.o
*.so
#This one will be in your home directory
*~
.idea

But it's not magical. Git doesn't know where your global gitignore file is. You have to tell it with this simple command:

git config --global core.excludesfile '~/.gitignore'
# You see, there is no fucking $ in the line above, and you understand it. Magic, isn't it ?

The evil way

Yes, there is an evil way. Not the way I described at the beginning of this article, but a much more evil way. Yes, it's possible. Have you ever heard about gitignore.io ? It's a tool that claims to help you to create gitignores. You simply get them from an api and they are here. You can also retrieve several gitignores from several technos merged into one. But it's not as cool as it looks like. First, they are using dirty $ in their bash command lines. Then, let's try some bash commands:

curl <https://www.gitignore.io/api/C>
curl <https://www.gitignore.io/api/C,C++>
curl <https://www.gitignore.io/api/C,C++,linux>

Their tool allow us to merge project ignored files and OS ignored files. That's a big big mistake. Even worse, it makes duplicates.

curl <https://www.gitignore.io/api/C,C++> 2>&- | wc -l # It prints 68
curl <https://www.gitignore.io/api/C,C++> 2>&- | grep -v '^#' | sort | uniq | wc -l # It prints 25

Yeah, there is a lot of duplicates. I just remove duplicates and commented lines. There is an empty line remaining. That means this gitignore could fit in 24 fucking lines. So why are you giving me 68 ? You have too many bandwidth and you want to waste it ?

Conclusion

Please never use gitignore.io again. Write your own gitignores, one per project plus a global one. If you want to use already done gitignores, please have a look to this repo, it's pretty good.

Blog TOC

- Posted in Emeraude Blog by with comments

Here is the list of all the posts I wrote. I will update it each time I add a new one.

Zeronet

C++

JavaScript

General

[JS] Variable declarations

- Posted in Emeraude Blog by with comments


I saw a lot of people misunderstanding the way variables are declared in JavaScript. It's very sad because declaring a variable is the simpliest feature of a lot of languages (some languages as OCaml can only define constant values). But, there is something way worse: some guides are writing bullshit about it. Reading this github readme gave me the idea of writing this article. So, let's talk about the old way of defining variables :


The "var" keyword

The readme file I linked above let suggested that the var keyword defines scoped variables. You're all wrong. Let's see an example:

if (true) {
  var bar = 42;
}
console.log(bar);

This code displays 42 in the stdout. But bar is defined in the condition block scope. So why can I access it from outside ? That's because the var keyword does not define scoped variable. Actually, it defines a variable in the current function scope, or in the current file scope. You cannot define global variables with the var keyword.

Without any keyword

Let's look at this code:

function foo() {
  bar = 42;
}
foo();
console.log(bar);

This code also displays 42 because if you do not use the var keyword, you define a global variable. But the readme linked above says it's bad to do this. But it does not tell why. Let's clarify it : a global variable is not dirty. Indeed, only this way of declaring one is dirty. Usage of an undefined variable should raise a ReferenceError. Furthermore, if you are using the strict mode, your code will not work. So, how can we define a global variable without this syntax ? It's really simple :

window.foo = 42; // in the browser
GLOBAL.foo = 42;  // in node.js

The "let" keyword

In the first paragraph, I said the var keyword is the old way. So, what's the new way ? ECMAScript 6 added the let keyword in june 2015. It has almost the same behaviour as var. The only difference is that the let keyword define a true scoped variable. So no, this code will not work:

"use strict";
if (true) {
  let bar = 42;
}
console.log(bar);

So, from now, I suggest you to replace all your var by the new let keyword. Note that it works natively in SpiderMonkey (the engine used in firefox), but it requires usage of the strict mode in V8 (the engine used in Google Chrome and node.js).

Conclusion

The variables declarations is a good illustration of the problem of JavaScript. We had to wait 20 fucking years to have a way to define scoped variables. The language has been badly designed, and it's something that can be felt when using it. The language could have been awesome if it had been well designed from the beginning. The same problem can be found in a much more serious way in PHP.

[C/C++] Include guards

- Posted in Emeraude Blog by with comments


What is it ?

Today I want to talk about include guards. For those who don't know what I mean, It's a macro that is defined at the top of a header file, like this:

#ifndef FILE_NAME_H_
# define FILE_NAME_H_
...
#endif

You probably already saw something similar. It prevents for double-inclusion and recursive-inclusion. As an example, let's write a file parent.h, a file grandparent.h and a file son.h like this:

/* grandparent.h */
#ifndef GRAND_PARENT_H_
# define GRAND_PARENT_H_
...
#endif

/* parent.h */
#include "grandparent.h"
...

/* son.h */
#include "parent.h"
#include "grandparent.h"
...

In the file son.h, we require parent.h, that requires grandparent.h. So, when the preprocessor will reach the second line, it will not include grandparent.h twice, because the macro GRAND_PARENT_H_ is already defined.

Inconveniences

You probably already know it, but this method, even if it works well, has a lot of inconveniences : - It's long to write. 3 fucking lines just to tell the compiler not to include the file several times. - It may result into conflicts, especially if you work with several libraries or with other people. This problem grows with your project size. - It requires to read all the file, that means you lost some milliseconds PER INCLUSION. On a big project, it could result in seconds, and even in minutes. - It's prone to mistakes. You just have to misspell the macro the first or the second time you write it to create compilation errors. - It defines a lot of useless macros that will never be re-used. It slows down the preprocessor (this point is similar to the third one).

Solution

You probably have already seen it in some source codes, it's the #pragma once directive. It solves each problem described above. The only drawback is that this solution is not standard, but almost each compiler supports it, even the dirty Microsoft Visual C++ one. It replaces well the three lines you wrote before, it does not define useless macros, and it avoids conflicts. It's even faster because it does not require to read all the file content, because it's builtin into the compiler and it's not a trick. It looks like a magical solution, especially if you never heard of it before. But let me ask you something : can we do something better ? You know, C has been released in 1972, and has barely changed (C99 and C11 added a few features, and this versions are not widespread). But C++ is an object oriented programming language based on C. It takes C and it adds some missing features to it. So, why have we to write the inclusion guards or the #pragma once directive ? Why isn't it a builtin of the language ? We never want to include a header file several times, so why do we have to precise it ?

NB: Concerning the last part, I know you may want to include another file than a header file, like a small part of C/C++ code that will be reused. But doing this is a bad thing, you do not have to re-use several times the same part of code. If you think you have to, just create a fucking function!

What's wrong with READMEs

- Posted in Emeraude Blog by with comments


I spend a lot of time testing new softwares, and I have to read a lot of README files. But, really often, I find bad repositories, with bad formatted readme. Or worse, no README at all. What the fuck ? How I am supposed to figure out how your code works if you don't give me a fucking clue ? But, sometimes, I see other big issues on readmes. First, the README.txt files on GitHub. HAVE YOU EVER WATCHED YOUR REPO ? Your shit is not parsed! GitHub only recognizes .md extension, and it's cool. Markdown is older than GitHub, even than git itself! What's wrong with you ? Why are you using inconsistent file extensions without any style ?


Well, bad file extensions are bad, but not very common. I want to tell you about something really really nastier: fucking $ in bash command lines, like that:

$ git clone <http://github.com/Kinto/kinto-heroku.git> --depth=1 kinto-instance && cd kinto-instance
$ heroku create && git push heroku master
$ heroku open

What the fuck ? Have you ever used it ? Have you ever tried to copy-paste the lines ? What's wrong with you ? It's dirty and the argument "But with this, you know it's bash command lines" is bullshit. Learn how to use fucking markdown.

```bash THIS means it's bash command lines
$ Not that !

So please, go fix your readme and open pull requests on repositories that do not respect conventions. It's good for you and it saves ponies.

Let's talk about shebangs

- Posted in Emeraude Blog by with comments


Shebangs are pretty useful. It allows you to tell which interpreter will be used. But, really often, you see misformed, dirty shebangs.


#!/usr/bin/bash

This is bad. Depending on the computer, it could work. Or maybe the exec path of bash is /bin/bash. Or maybe it's not system-wide installed. You have to use this kind of shebangs:

#!/usr/bin/env bash

With this one, no problem. It will find the execution path correctly. But, I often see other dirty things. Something pretty awful, specitic to python language. Today, there are two versions of python still maintained and widely used. They are python2 and python3. Even if python3 is 8 years old, a lot of people are still using python2. Why not. It's probably not the best thing to do, but using a language based on indentation is basically a bad idea. The problem is that depending on the machine, python may redirect to python2 OR python3, YOU CANNOT KNOW. It's why you HAVE TO use one of the following:

#!/usr/bin/env python2
#!/usr/bin/env python3

Note that you have also access to python2.7 and python3.5, but they are not really interesting, because if the guy updates his python to python3.6 when it will be available, your code will not work anymore.

Welcome

- Posted in Emeraude Blog by with comments

Hi all, here is my blog. I will share some tips here, and a little bit of rage, too.