

Show HN: Simple wiki server written in Go - Spiritus
https://github.com/renstrom/go-wiki

======
lettergram
I wrote a similar project a while back, you might be interested in checking
out.

A friend and I implemented cookies, user login and database. However, I would
recommend not using the SHA2 encryption method we used (we did it for fun not
for security).

[https://github.com/lettergram/neptune](https://github.com/lettergram/neptune)

------
anton_gogolev
Whar bothers me in Go (and Python and Ruby, for that matteR) is that there's a
strange mix of human-friendly identifiers like ResponseWriter, ParseInt, etc.
and old-style Unix'y ones, like stdout, strconv, Println. Wildly inconsistent.

I wonder if "creat" is a valid function call somewhere.

~~~
natebrennand
FWIW, the Golang core developers regret using the old UNIX conventions in
packages. I don't think it's viable at this stage to take them back, but they
do agree that it doesn't fit the language well.

[http://gophercon.sourcegraph.com/post/83845316771/panel-
disc...](http://gophercon.sourcegraph.com/post/83845316771/panel-discussion-
with-go-team-members)

~~~
mseepgood
I think he only regrets having used upper case names for constants
(os.O_RDONLY), which is not idiomatic Go.

------
Spiritus
Author here. As mentioned in the README I created this project as a process to
learn to Go.

I'm actually quite happy with how it turned out, I wanted something really
simple to use but still have some nice features like showing the history of a
page by leveraging Git.

Unfortunately I didn't get to use channels... Yet.

Coming from a Python background mostly I found Go pretty pleasing to work,
however it took a while for me to grok the whole `$GOPATH` and dependencies
stuff.

------
dmunoz
Good job. I see you went a few steps further than the Writing Web Applications
with Go tutorial [0]. Definitely a good way to learn. I like your idea of
showing the git history including diffs.

For anyone who might be interested in Go and is wondering how this is done,
read the tutorial I mentioned. Go has solid documentation alongside a handful
of tutorial style article that are worth reading.

[0]
[http://golang.org/doc/articles/wiki/](http://golang.org/doc/articles/wiki/)

------
Pinn2
As usual, I checked the .gitignore. You may want to try "/gowiki" instead of
"gowiki".

~~~
Spiritus
That makes sense. Just pushed a fix[1].

[1] [https://github.com/renstrom/go-
wiki/commit/535c645fb25252e49...](https://github.com/renstrom/go-
wiki/commit/535c645fb25252e496396883db8c61fc462ddf6c)

------
rco8786
Interesting considering Rob's recent defense of the state of Go error
handling.

var err error tail.Stdin, err = git.StdoutPipe() if err != nil {
log.Println("ERROR", err) }

tail.Stdout = &out

err = tail.Start() if err != nil { log.Println("ERROR", err) }

err = git.Run() if err != nil { log.Println("ERROR", err) }

err = tail.Wait() if err != nil { log.Println("ERROR", err) }

~~~
Spiritus
Yes, not my proudest moment. To be honest, I wasn't really sure what to with
all the err's.

~~~
buro9
The only issue I'd really be strict about is that you're not doing _anything_
with the errors.

Specifically, you've:

1\. Encountered an error

2\. Detected it

3\. Printed it

But you've continued execution, and some of those errors are clearly not going
to let you continue cleanly.

If you couldn't call git on the command line (i.e. it is not installed), then
what are you going to do with the stdout? And if git was somehow replaced with
something that only returned a status code and no output, then what are you
going to do with no output?

The important point is that errors can be thrown because errors can plausibly
exist in a way that affects you. You _should_ handle them, logging is fine as
a bare minimum but you probably also want to return and exit out of the func
in a way that communicates to the thing that called the func that "Something
went wrong, and I don't have the results you're looking for".

~~~
Spiritus
I agree. I should probably just add something like this at after every log:

    
    
        log.Println("ERROR", err)
        return out.Bytes(), err
    

Or just:

    
    
        log.Println("ERROR", err)
        return []byte, err
    

But I figured since the error will eventually get returned at the end anyway I
moved on and kind of forgot about it.

