I'm writing a web application in Go. So far I've written all base libraries I'm going to need for now and that worked out just perfect. The package structure is really handy in that aspect.
Now I'm at the point where I need to start writing the application itself, the business logic. I'm a little lost of how or where this code should go.
I've watched and read pretty much every application development tutorial/walkthrough on the official documentation page and they always write the entire domain logic in the main package/namespace.
Is this the way to Go (sorry, had to) or was it just for the sake of simplicity?
Putting the business layer into packages feels uncomfortably wrong in my opinion.
No, it does not have to be all in the same package. You can easily make a new directory, put your code for that package there, and import it from your main package. It's simple as that.
You may want to look at go-tour as a simple web app that consists of a few small packages (pic, wc, ...). If you want to see organization of a big Go app see Camlistore. Both of these are written by Go Authors, so they can be considered nice examples.
I just have to say that writing small, reusable, and separate packages is very common in Go, and that reduces the size of the main codebase of apps.
Related
A bit of background:
I am a pentester who is looking for new ways to get around AV detection during tests / bounties and I recently found the Go library "Coldfire" on Github. I am new to Go so I was wondering how I would structure a project with this package.
It doesn't give much instructions except the func that it uses and I am coming from Python.
https://github.com/redcode-labs/Coldfire
If anyone can give me some tips, I am trying to write an AV evasion program that will kill AV processes and possibly disable a WAF.
You don't have to give me full code or anything, I just would like some examples on how to use the package is all. Thank you so much and please excuse my lack of knowledge I love Go but am very new to it and trying to learn it respective to my profession.
Not really interested in Disruptive functions but with the recent outbreak in Go malware I would love to understand how malicious attackers use those functions too if possible.
I imported the library but it kept giving me an error saying I wasn't using the package even though I had implemented some of the functions to see what they did.
Not sure what goes in said func like..
func PkillAv()
Not sure what would go in the {} on this one or if I would even need it.
You would just need to import it at the top part of your code like:
import "github.com/redcode-labs/Coldfire"
You also need to run
go mod tidy
To download this package.
After that you can use the functions provided in the package. There is no "structure" that you need to manualy create
I'm writing a fairly simple application in Go, more as a learning tool than anything else.
What I'd really like to do is to organise my code somewhat - for example, I've separated out some Hipchat API commands into a separate file. Right now, it's still under the main package, but I'd prefer to move it (namespace it) into a kind of subpackage. The thing is, Go seems to think that such a package should live in my $GOPATH, despite it not being relevant to any project besides the one it's being written for.
I'm probably trying to misuse the package functionality, so if so, what's the best way to achieve what I'm trying to do?
Thanks to the pointers from tkausl in comments left on my question, I figured out the way to achieve exactly what I wanted. I moved my project to reside in $GOPATH and then accessed the sub-package via import subpackage from "project/subpackage".
Wouldn't have got there for a while without that help! Just a case of learning Go's way of doing things.
The situation is as follows:
I am trying to define a path in which a certain character travels in a game. This can be done by typing all coordinates for such path. However, this requires a lot of testing, recompiling, as you try to view such path in the product and see if it is what you wanted. This is very tedious
Clearly there is no Graphical Interface built in for every purpose, and obviously also for this case. Then, I proceed to built another application/ another few files that serve as a custom graphical interface for my path class: for editing paths by coordinates and change it interactively.
This does not really cause a problem. However, such an application does not fit in the app, nor make sense to be an application just for programming a specific class. Additionally, if I want to have an application for each of my more complicated data structures, it becomes very messy and hard to manage.
I recall that there is a playground feature in swift. This is perfect for me as it is interactive. And I am thinking:
Is there a way to programme an playground-similar application inside the same project?
(Since I demand programming to be pretty) Can this be done without switching to different projects just for this purpose? Is there such a feature?
Equivalently, is there a way to programme something that helps programming within swift, such as an extension for swift?
Again, I emphasis that, this is needed only for saving troubles and making an application more self-contained.
Turns out to be a stupid question. There is obviously an option in adding a new playground file to existing project.
I have used backbone boilerplate on the past
https://github.com/backbone-boilerplate/backbone-boilerplate
I want to use marionette on my next project and I have found this
https://github.com/BoilerplateMVC/Marionette-Require-Boilerplate
My question is if it's a good idea to go with the marionette boilerplate or start form scratch.
As an aside, I'd like to suggest you give Yeoman a shot for scaffolding your first Marionette app. Yeoman works via what are called "generators", and provide much more than the the above Boilerplate MVC can offer you (Chai and Sinon for testing, Bower for client-side package management, etc...). Plus, Addy Osmani, who runs backbone-boilerplates is one of the heads of the project. Check out generator-marionette here.
I haven't used BoilerPlate, but glancing through it, it certainly seems like a valid approach to writing Marionette apps. If you're just getting started it will certainly help you see how the various pieces are supposed to be used. One gripe I've got is the folder structure. I prefer to break my applications down into modules, and then add models, collections, views, etc under each module. But this will certainly get you up and running quick, and there's nothing stopping you from customizing it to suit your needs.
I agree with others here: it is a useless limitation to imitate a folder structure that follows the 'old mvc model for server-side code'. You will remain more flexible further down the road if you think of your application strictly as completely self-containing modules, i.e. they contain their own controller/router/views/collections/templates etc. You can have a separate folder structure for shared code that is not a module, although anything can be made a module :)
Regarding boilerplate code and generators: i think in the beginning you should actually NOT do it, because you won't understand what you're doing. But that's just my personal opinion.
What are some of the best practices for OOD with Ruby? Mainly, how should files and code be organized?
I have a project that uses several classes and files and I am just wondering how it should all be organized, grouped and included.
It sounds like you're asking which pieces go in which files.
Is your project a Web application? In that case you would most likely use the system of organization imposed by your framework (Rails, Merb, Sinatra, etc.)
Other kinds of projects also have their own typical structure that you can just follow. E.g. gems are usually set up in a certain way.
If it's a console app, there's no strict rule. Usually people put no more than one class or module in a file. You could have one main file that requires all the others.
Standard OOD concepts apply to ruby. For specifics, maybe this guide will be helpful:
http://www.rubyist.net/~slagell/ruby/oothinking.html