Re: [go-nuts] About source folder organization - Part II

[Victor Giordano]

Eli, thanks for the insight. Is a very interesting read!.

>There are a number of different options and no right or wrong answer.
*Exactly! *I never say that there was a right or wrong answer.
I'm looking to see other real file projects in order to gather more
opinions along with something like a "code map"  that highlights why the
folder are named like that.

Regarding the reading.

> The same applies to the files-and-directories layout of a project. No
single layout fits all purposes.

Well that is true. I mean, I do see a lot of times projects where are
folder that are based on problem's domain affairs and some folder based on
solution's domain affairs... for example, in the context of an app where
you generate reports of things, you may find at the same folder something
like:

/reports (domain's level)
/websockets (solution's level)

and there is a mix of criteria used for determining the hierarchies of the
fs. This happens a lot, as far as I have seen (and also happens to me!).

Is very interesting... but I do found things.. for example... having at the
same level something like "assets" and "webserver", what about the assests
a web server uses? Well... have a lot to read.

Thanks again.


El mar, 21 mar 2023 a las 11:38, Eli Lindsey ()
escribió:

> There are a number of different options and no right or wrong answer.
> This was a recent blog that I thought did an excellent job of summarizing
> some of the more common layouts and trade offs
> https://appliedgo.com/blog/go-project-layout
>
> -eli
>
> On Mar 21, 2023, at 10:28 AM, Victor Giordano 
> wrote:
>
> Hello fellows gophers!
>
> I do wonder how you organize a project within a file system. Due to the
> hierarchical nature of a fs (where is parent folder that constains child
> folder) I do wonder how do you organize the source files into folders. Can
> you show me some examples?
>
> For example, here  is a project
> about a cards game server (Escobita de 15) and also a presentation is
> provided in order to be usable by a web browser (a front)
>
> You may also peak the code map
>  file that
> directly describes what it is in each directory.
>
> Well, if any of you can share a project for the sake of understanding how
> do you organize your sources files I would be greatfull. A code map file
> would be nice too! (But I know that may be is to much to ask!)
>
> Greettings
> Víctor
>
> I tried to talk about this
>  but doesn't get
> too much insight, so now I'm trying to be more practical (instead of
> theorical like before).
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/51265059-3821-4f42-b85d-606c3e175fc3n%40googlegroups.com
> 
> .
>
>

-- 
V

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAPUu9ssPDpLx2ygbdfdT4nbAX8ibw2rtDryRxcSn_Pi5eSnv0w%40mail.gmail.com.

Re: [go-nuts] About source folder organization - Part II

[Eli Lindsey]

There are a number of different options and no right or wrong answer. This was a recent blog that I thought did an excellent job of summarizing some of the more common layouts and trade offs https://appliedgo.com/blog/go-project-layout-eli On Mar 21, 2023, at 10:28 AM, Victor Giordano  wrote:Hello fellows gophers!I do wonder how you organize a project within a file system. Due to the hierarchical nature of a fs (where is parent folder that constains child folder) I do wonder how do you organize the source files into folders. Can you show me some examples?For example, here is a project about a cards game server (Escobita de 15) and also a presentation is provided in order to be usable by a web browser (a front)You may also peak the code map file that directly describes what it is in each directory.Well, if any of you can share a project for the sake of understanding how do you organize your sources files I would be greatfull. A code map file would be nice too! (But I know that may be is to much to ask!)GreettingsVíctorI tried to talk about this but doesn't get too much insight, so now I'm trying to be more practical (instead of theorical like before).



-- 
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/51265059-3821-4f42-b85d-606c3e175fc3n%40googlegroups.com.




-- 
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/1D52B13C-6B2E-4E3C-A2C4-882428B1C502%40siliconsprawl.com.

Re: [go-nuts] About source folder organization

[Victor Giordano]

Jan, Volker... i will try you to summon over here

!
There is another person with some kind of the same problems i were... he is
trying to organize code in packages and maybe overthinking.

El jue., 15 nov. 2018 a las 14:37, Victor Giordano ()
escribió:

> For your information people, i'm trying to open my mind for embracing the
> concept of packages without any trace of the hierarchical relation of
> underlying file system in mind!
> Thanks again for your valuable opinions. I really needed someone to talk
> about this, i love doing code/patterns/idioms teraphy!.
>
> *V*
>
>> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] About source folder organization

[Victor Giordano]

For your information people, i'm trying to open my mind for embracing the 
concept of packages without any trace of the hierarchical relation of 
underlying file system in mind!
Thanks again for your valuable opinions. I really needed someone to talk 
about this, i love doing code/patterns/idioms teraphy!.

*V*

>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] About source folder organization

[Victor Giordano]

Thanks for pointing that out.

*V*

El jue., 15 nov. 2018 a las 12:56, Jan Mercl (<0xj...@gmail.com>) escribió:

> On Thu, Nov 15, 2018 at 4:51 PM Victor Giordano 
> wrote:
>
> > You may say that i'm a little stubborn but what after i look at others
> source files i do notice that they do not reference "childs" packages from
> "parents"
> > (please allow me to use those words, again...)or can you tell me of the
> opossite thing?
>
> For example here:
> https://github.com/golang/go/blob/master/src/regexp/regexp.go#L70
>
>
>
>
> --
>
> -j
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] About source folder organization

[Jan Mercl]

On Thu, Nov 15, 2018 at 4:51 PM Victor Giordano 
wrote:

> You may say that i'm a little stubborn but what after i look at others
source files i do notice that they do not reference "childs" packages from
"parents"
> (please allow me to use those words, again...)or can you tell me of the
opossite thing?

For example here:
https://github.com/golang/go/blob/master/src/regexp/regexp.go#L70




-- 

-j

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] About source folder organization

[Victor Giordano]

Hello Volker! Thanks for your feedback.
The overthinking is direct consecuencie of two things: having time and 
don't have TV at home :P. 

I have a felling that what you are trying to say me is to: just forget a 
little bit over the underlying storage system for the files, and focus only 
in the package concepts as an abstraction, and the only "hard" rule they 
have is that they can not be referenced in a circular fashion. Thas is ok!. 
I got it.
You may say that i'm a little stubborn but what after i look at others 
source files i do notice that they do not reference "childs" packages from 
"parents" (please allow me to use those words, again...)or can you tell me 
of the opossite thing? I mean, someone or a project that actually constains 
at least a source file that imports a package located in sub directory.  If 
nobody uses that pattern that may say something about how "we work" (you 
probably say that i overthing a lot, but for me i'm realizing observations 
over other people work). What i may try to discover here is a, you may call 
it, "soft" rule. BTW: Recall that packages introduces namespaces, and 
namepsaces are important for code organization.

V




El jueves, 15 de noviembre de 2018, 5:04:01 (UTC-3), Volker Dobler escribió:
>
> My opinion on this: You are overthinking it. A lot.
>
> Let's start simple. Cyclic dependencies between packages
> are disallowed and whatever you do you packages must not
> for an import cycle. This is the only hard rule. Note that this
> rule is totally decoupled from the filesystem layout of your
> packages.
>
> The last point already hints at why I believe you are overthinking
> the importance of the file system layout: It simply does influence
> the one and only package rule.
>
> Well, almost. There are two (I hope I did not forget one) special
> file system folder names: "internal" and "vendor" and these do have
> special semantics on how package lookup works. But these are
> not at the heart of you question as far as I understand your question.
>
> For the rest: Package spread on the filesystem is guided by the
> following aspect:
> You import by file system path so this hierarchical path can
> be used to transport information to the reader of your code:
> import "net/http/cookiejar"
> and
> import "household/kitchen/cookiejar"
> will bot import a cookie jar but what type of jar this will be is
> nicely explained in the file system path.
> The file system also lets you group stuff that belongs together
> logically or how it is used. Peek at the stdlib: In folder
> encoding you will find lots of different encodings.
>
> Note that this is a logical grouping and not a technical.
> There are no "parent" and no "child" packages in Go. Do not
> think about file system layout as parent/child, top/sub, whatever.
> It is not. It is file system layout. Just like you would organize
> your documents: You might do
> documents/house/official to store bill of sale and property tax
> and and documents/house/bills/garden to keep your landscapers
> bills while putting general stuff into documents/house to keep
> the separate from documents/school. You organize, but this does
> not introduce a parent/top/abstract - child/sub/concrete relationship
> between these documents.
>
> Filesystem layout is (apart from internal and vendor) to group
> packages logically and not technically. Do not overthink it.
>
> V.
>
>
>
> On Thursday, 15 November 2018 01:38:52 UTC+1, Victor Giordano wrote:
>>
>> Thanks Jan. Then i shall paste the question here. I copy paste the 
>> question as it was writed at first place in order to honor an idempotent 
>> behvaiour (recall that the question was edited in stackoverflow for 
>> improving understanding). Thanks in advance for all that take the time for 
>> reading!.
>>
>> *Original question*
>> The motivation behind this question is to obtain feedback of the 
>> commutity (specificially the golang devs) about something that keeps me 
>> wondering. The question itself is related to source files organization in a 
>> software , something that is an affair of every programmer that works in 
>> "industrial-strength software" (to quote my Dear Graddy Booch). In this 
>> case i sit over a project that employs golang as server programming tool.
>>
>> Let's starts assuming that there is a lots programming concepts out-there 
>> that are language agnostic, i mean they do not belong to an specific 
>> language; for example the one thing i'm pointing out here: laying out the 
>> source files accross folders, is not something that is exclusive to a 
>> particular language.
>>
>> Due to the hierarchical nature of file system, i would expect that others 
>> persons also wonder what about the meaning of those files across the 
>> folders, there is a reason for laying out the files in specifics folder 
>> right? (i wonder)... or, sitting on the opposite side of thinking, shall we 
>> put everthing on a single folder?... i mean, c'mon... we know the answer. 
>> 

Re: [go-nuts] About source folder organization

[Volker Dobler]

Ooops:

This should read

It simply does *NOT* influence the one and only package rule.

On Thursday, 15 November 2018 09:04:01 UTC+1, Volker Dobler wrote:
>
> My opinion on this: You are overthinking it. A lot.
>
> Let's start simple. Cyclic dependencies between packages
> are disallowed and whatever you do you packages must not
> for an import cycle. This is the only hard rule. Note that this
> rule is totally decoupled from the filesystem layout of your
> packages.
>
> The last point already hints at why I believe you are overthinking
> the importance of the file system layout: It simply does influence
> the one and only package rule.
>
> Well, almost. There are two (I hope I did not forget one) special
> file system folder names: "internal" and "vendor" and these do have
> special semantics on how package lookup works. But these are
> not at the heart of you question as far as I understand your question.
>
> For the rest: Package spread on the filesystem is guided by the
> following aspect:
> You import by file system path so this hierarchical path can
> be used to transport information to the reader of your code:
> import "net/http/cookiejar"
> and
> import "household/kitchen/cookiejar"
> will bot import a cookie jar but what type of jar this will be is
> nicely explained in the file system path.
> The file system also lets you group stuff that belongs together
> logically or how it is used. Peek at the stdlib: In folder
> encoding you will find lots of different encodings.
>
> Note that this is a logical grouping and not a technical.
> There are no "parent" and no "child" packages in Go. Do not
> think about file system layout as parent/child, top/sub, whatever.
> It is not. It is file system layout. Just like you would organize
> your documents: You might do
> documents/house/official to store bill of sale and property tax
> and and documents/house/bills/garden to keep your landscapers
> bills while putting general stuff into documents/house to keep
> the separate from documents/school. You organize, but this does
> not introduce a parent/top/abstract - child/sub/concrete relationship
> between these documents.
>
> Filesystem layout is (apart from internal and vendor) to group
> packages logically and not technically. Do not overthink it.
>
> V.
>
>
>
> On Thursday, 15 November 2018 01:38:52 UTC+1, Victor Giordano wrote:
>>
>> Thanks Jan. Then i shall paste the question here. I copy paste the 
>> question as it was writed at first place in order to honor an idempotent 
>> behvaiour (recall that the question was edited in stackoverflow for 
>> improving understanding). Thanks in advance for all that take the time for 
>> reading!.
>>
>> *Original question*
>> The motivation behind this question is to obtain feedback of the 
>> commutity (specificially the golang devs) about something that keeps me 
>> wondering. The question itself is related to source files organization in a 
>> software , something that is an affair of every programmer that works in 
>> "industrial-strength software" (to quote my Dear Graddy Booch). In this 
>> case i sit over a project that employs golang as server programming tool.
>>
>> Let's starts assuming that there is a lots programming concepts out-there 
>> that are language agnostic, i mean they do not belong to an specific 
>> language; for example the one thing i'm pointing out here: laying out the 
>> source files accross folders, is not something that is exclusive to a 
>> particular language.
>>
>> Due to the hierarchical nature of file system, i would expect that others 
>> persons also wonder what about the meaning of those files across the 
>> folders, there is a reason for laying out the files in specifics folder 
>> right? (i wonder)... or, sitting on the opposite side of thinking, shall we 
>> put everthing on a single folder?... i mean, c'mon... we know the answer. 
>> No single folder as it's not quite good for growing projects.
>>
>> It is says that in golang packages doesn't follow any hierharchy, but the 
>> source files relies on a concrete hierarchical file system. So there is 
>> grey area here for a person that see the whole image, because package 
>> doens't follow hierchary but the source files yes, and, after all we work 
>> over source files. So after inspecting some source codes of the authors of 
>> the language (https://golang.org/src/) i do notice that from a parent 
>> package there is no reference to any child pacakge. Although i do not make 
>> an exhaustive exploration of the source files, i started to wonder if that 
>> actually says something about how people think (in a golang based project, 
>> important detail), basically, how we think. It could be taken as a rule 
>> thumb? I Mean for example stating something like this: "devs tend to not 
>> reference package implemented in subfolders of the same hierarchy". I mean, 
>> that is something (actually a lot), at least for me. Let me put this on 
>> these words: it is saying that 

Re: [go-nuts] About source folder organization

[Volker Dobler]

My opinion on this: You are overthinking it. A lot.

Let's start simple. Cyclic dependencies between packages
are disallowed and whatever you do you packages must not
for an import cycle. This is the only hard rule. Note that this
rule is totally decoupled from the filesystem layout of your
packages.

The last point already hints at why I believe you are overthinking
the importance of the file system layout: It simply does influence
the one and only package rule.

Well, almost. There are two (I hope I did not forget one) special
file system folder names: "internal" and "vendor" and these do have
special semantics on how package lookup works. But these are
not at the heart of you question as far as I understand your question.

For the rest: Package spread on the filesystem is guided by the
following aspect:
You import by file system path so this hierarchical path can
be used to transport information to the reader of your code:
import "net/http/cookiejar"
and
import "household/kitchen/cookiejar"
will bot import a cookie jar but what type of jar this will be is
nicely explained in the file system path.
The file system also lets you group stuff that belongs together
logically or how it is used. Peek at the stdlib: In folder
encoding you will find lots of different encodings.

Note that this is a logical grouping and not a technical.
There are no "parent" and no "child" packages in Go. Do not
think about file system layout as parent/child, top/sub, whatever.
It is not. It is file system layout. Just like you would organize
your documents: You might do
documents/house/official to store bill of sale and property tax
and and documents/house/bills/garden to keep your landscapers
bills while putting general stuff into documents/house to keep
the separate from documents/school. You organize, but this does
not introduce a parent/top/abstract - child/sub/concrete relationship
between these documents.

Filesystem layout is (apart from internal and vendor) to group
packages logically and not technically. Do not overthink it.

V.



On Thursday, 15 November 2018 01:38:52 UTC+1, Victor Giordano wrote:
>
> Thanks Jan. Then i shall paste the question here. I copy paste the 
> question as it was writed at first place in order to honor an idempotent 
> behvaiour (recall that the question was edited in stackoverflow for 
> improving understanding). Thanks in advance for all that take the time for 
> reading!.
>
> *Original question*
> The motivation behind this question is to obtain feedback of the commutity 
> (specificially the golang devs) about something that keeps me wondering. 
> The question itself is related to source files organization in a software , 
> something that is an affair of every programmer that works in 
> "industrial-strength software" (to quote my Dear Graddy Booch). In this 
> case i sit over a project that employs golang as server programming tool.
>
> Let's starts assuming that there is a lots programming concepts out-there 
> that are language agnostic, i mean they do not belong to an specific 
> language; for example the one thing i'm pointing out here: laying out the 
> source files accross folders, is not something that is exclusive to a 
> particular language.
>
> Due to the hierarchical nature of file system, i would expect that others 
> persons also wonder what about the meaning of those files across the 
> folders, there is a reason for laying out the files in specifics folder 
> right? (i wonder)... or, sitting on the opposite side of thinking, shall we 
> put everthing on a single folder?... i mean, c'mon... we know the answer. 
> No single folder as it's not quite good for growing projects.
>
> It is says that in golang packages doesn't follow any hierharchy, but the 
> source files relies on a concrete hierarchical file system. So there is 
> grey area here for a person that see the whole image, because package 
> doens't follow hierchary but the source files yes, and, after all we work 
> over source files. So after inspecting some source codes of the authors of 
> the language (https://golang.org/src/) i do notice that from a parent 
> package there is no reference to any child pacakge. Although i do not make 
> an exhaustive exploration of the source files, i started to wonder if that 
> actually says something about how people think (in a golang based project, 
> important detail), basically, how we think. It could be taken as a rule 
> thumb? I Mean for example stating something like this: "devs tend to not 
> reference package implemented in subfolders of the same hierarchy". I mean, 
> that is something (actually a lot), at least for me. Let me put this on 
> these words: it is saying that the abstractions (or exported members) 
> located in "parent" packages doesn't know any of the astractions located in 
> "childs" packages, or at least, not directly. And i would say that this 
> could be seen as a design principle.
>
> What are "parent" and "child" package:
>
> I'm 

Re: [go-nuts] About source folder organization

[Jan Mercl]

On Thu, Nov 15, 2018 at 8:52 AM Jan Mercl <0xj...@gmail.com> wrote:

Fixing it

example.com/foo can import example.com/bar: siblings vs "parent" and
"child".

example.com/foo can import example.com/foo/a but in the same time
example.com/foo/b  can import example.com/foo
: "parent" and "child" meaning can be inverted or not.

-- 

-j

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] About source folder organization

[Jan Mercl]

On Thu, Nov 15, 2018 at 1:38 AM Victor Giordano 
wrote:

example.com/foo can import example.com/bar: siblings vs "parent" and
"child".

example.com/foo can import example.com/foo/a but in the same time
example.com/b can import example.com: "parent" and "child" meaning can be
inverted or not.

The conclusion is that there are no "parent"/"child" packages or
"subpackages". Just packages that import other packages. It's true that the
dependency graph must be a tree (acyclic), but that tree is independent of
the import path hierarchy.

-- 

-j

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] About source folder organization

[Victor Giordano]

Thanks Jan. Then i shall paste the question here. I copy paste the question
as it was writed at first place in order to honor an idempotent behvaiour
(recall that the question was edited in stackoverflow for improving
understanding). Thanks in advance for all that take the time for reading!.

*Original question*
The motivation behind this question is to obtain feedback of the commutity
(specificially the golang devs) about something that keeps me wondering.
The question itself is related to source files organization in a software ,
something that is an affair of every programmer that works in
"industrial-strength software" (to quote my Dear Graddy Booch). In this
case i sit over a project that employs golang as server programming tool.

Let's starts assuming that there is a lots programming concepts out-there
that are language agnostic, i mean they do not belong to an specific
language; for example the one thing i'm pointing out here: laying out the
source files accross folders, is not something that is exclusive to a
particular language.

Due to the hierarchical nature of file system, i would expect that others
persons also wonder what about the meaning of those files across the
folders, there is a reason for laying out the files in specifics folder
right? (i wonder)... or, sitting on the opposite side of thinking, shall we
put everthing on a single folder?... i mean, c'mon... we know the answer.
No single folder as it's not quite good for growing projects.

It is says that in golang packages doesn't follow any hierharchy, but the
source files relies on a concrete hierarchical file system. So there is
grey area here for a person that see the whole image, because package
doens't follow hierchary but the source files yes, and, after all we work
over source files. So after inspecting some source codes of the authors of
the language (https://golang.org/src/) i do notice that from a parent
package there is no reference to any child pacakge. Although i do not make
an exhaustive exploration of the source files, i started to wonder if that
actually says something about how people think (in a golang based project,
important detail), basically, how we think. It could be taken as a rule
thumb? I Mean for example stating something like this: "devs tend to not
reference package implemented in subfolders of the same hierarchy". I mean,
that is something (actually a lot), at least for me. Let me put this on
these words: it is saying that the abstractions (or exported members)
located in "parent" packages doesn't know any of the astractions located in
"childs" packages, or at least, not directly. And i would say that this
could be seen as a design principle.

What are "parent" and "child" package:

I'm talking about two "kinds" of packages, parent and child. Parent is the
one located in a directory (parent) and child is one located in a
subdirectory of the former (parent/child). Plese forgive if my words aren't
addecuate, focus on the concepts. For those that never work with packages
outside golang, try to bear with me and allow me to use those inappropriate
words for trying to explain.

I'm editing this question because i do think that mi intend was not so
clear, my intend is to gather other devs feedback about this, if they ever
wonder it; so the answer could answer yes, maybe no, maybe you don't care
about it because never stop to reason about it or see a pattern. I do not
know if the question is opinion based or not, but i guess is pretty clear
my point, i mean the kind of feedback, and eventually, and answer of course
(that may can be built together, why not? its not the sum of relativities
the absolute true? (Chuang Tzu). I think these thoughts should be written
somewhere, after all, it is knowledge about something, i guess here will
fit better for a start)

I would like to hear other devs thoughts about this, perhaps i'm the first
person on the comminity to point this out (but surely not the only one who
thought about this), and viola!!

I'm eager to read your feedback.

El mié., 14 nov. 2018 a las 16:40, Jan Mercl (<0xj...@gmail.com>) escribió:

> Yes, that's it.
>
> I see:
>
> "This question was removed from Stack Overflow for reasons of moderation.
> Please refer to the help center for possible explanations why a question
> might be removed.
> ..."
>
> On Wed, Nov 14, 2018, 20:37 Victor Giordano  wrote:
>
>> Hello jan!
>> So, what are you trying to say is that you follow the link and see
>> nothing?
>>
>> El mié., 14 nov. 2018 a las 16:07, Jan Mercl (<0xj...@gmail.com>)
>> escribió:
>>
>>> It's already removed on SO.
>>>
>>> On Wed, Nov 14, 2018, 20:00 Victor Giordano 
>>> wrote:
>>>
 hello gophers!! how you doing?

 Some time ago i posted this
 
  in
 other CoP (community of practices),  don't go ahead wihtout reading the
 above two lines (or four and 

Re: [go-nuts] About source folder organization

[Jan Mercl]

Yes, that's it.

I see:

"This question was removed from Stack Overflow for reasons of moderation.
Please refer to the help center for possible explanations why a question
might be removed.
..."

On Wed, Nov 14, 2018, 20:37 Victor Giordano  wrote:

> Hello jan!
> So, what are you trying to say is that you follow the link and see nothing?
>
> El mié., 14 nov. 2018 a las 16:07, Jan Mercl (<0xj...@gmail.com>)
> escribió:
>
>> It's already removed on SO.
>>
>> On Wed, Nov 14, 2018, 20:00 Victor Giordano 
>> wrote:
>>
>>> hello gophers!! how you doing?
>>>
>>> Some time ago i posted this
>>> 
>>>  in
>>> other CoP (community of practices),  don't go ahead wihtout reading the
>>> above two lines (or four and you get a thanks for free :P)
>>> At first place that post doesn't get understood by the community over,
>>> so i edited to be far more than clear.
>>> if you want, take some minutes, and read it, and, i will be expecting
>>> your opinion as a collegue.
>>>
>>> Thanks in advance!
>>> V
>>>
>>>
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "golang-nuts" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to golang-nuts+unsubscr...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>> --
>>
>> -j
>>
> --

-j

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] About source folder organization

[Victor Giordano]

Hello jan!
So, what are you trying to say is that you follow the link and see nothing?

El mié., 14 nov. 2018 a las 16:07, Jan Mercl (<0xj...@gmail.com>) escribió:

> It's already removed on SO.
>
> On Wed, Nov 14, 2018, 20:00 Victor Giordano  wrote:
>
>> hello gophers!! how you doing?
>>
>> Some time ago i posted this
>> 
>>  in
>> other CoP (community of practices),  don't go ahead wihtout reading the
>> above two lines (or four and you get a thanks for free :P)
>> At first place that post doesn't get understood by the community over, so
>> i edited to be far more than clear.
>> if you want, take some minutes, and read it, and, i will be expecting
>> your opinion as a collegue.
>>
>> Thanks in advance!
>> V
>>
>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to golang-nuts+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
> --
>
> -j
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] About source folder organization

[Jan Mercl]

It's already removed on SO.

On Wed, Nov 14, 2018, 20:00 Victor Giordano  wrote:

> hello gophers!! how you doing?
>
> Some time ago i posted this
> 
>  in
> other CoP (community of practices),  don't go ahead wihtout reading the
> above two lines (or four and you get a thanks for free :P)
> At first place that post doesn't get understood by the community over, so
> i edited to be far more than clear.
> if you want, take some minutes, and read it, and, i will be expecting your
> opinion as a collegue.
>
> Thanks in advance!
> V
>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
-- 

-j

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.