No hay pregunta estúpida

Kaledros

Bienvenidos a la primera edición de "no hay pregunta estúpida", soy su anfitrión, Kaledros.

Abro este hilo para que a nadie le dé palo preguntar algo que no entiende y que cree que es una pregunta estúpida o que a estas alturas debería entenderlo por sí mismo. Nadie nace aprendido y hay cosas que cuestan más de entender que otras. La única regla de este hilo es no ser un imbécil. Esto no es feda, no saquemos los pies del tiesto y seamos amables, puede que mañana seamos nosotros quienes preguntemos algo aquí.

Empiezo yo, que para eso abro el hilo: ¿para qué se usan los canales direccionales en Go en la práctica? Entiendo como funcionan, entiendo lo que no se debe hacer y lo que sí, pero no se me ocurre un solo caso de uso ahora mismo, supongo que porque nunca he tenido la necesidad de usar nada parecido. ¿Por qué iba a querer yo un canal donde sólo puedo escribir y me da un panic al leerlo?

Es decir, esto:

package main

import "fmt"

func something() <-chan int {
	c := make(chan int)

go func() {
	defer close(c)
	c <- 123
}()

return c
}

func main() {
	fmt.Println(<-something())
}

Dentro de something() se crea un canal normal pero como lo castea según el return de la función lo que se obtiene al invocarla es un canal de sólo lectura. Imagino que esto lo que consigue es una especie de inmutabilidad porque cuando devuelve el canal no puedes escribir en él sin que te suelte un panic al castearlo.

¿Es esto correcto? ¿Los canales readonly se usan para algo más? ¿Para qué se usa entonces un canal writeonly?

3
radykal

En nuestro caso, es un poco la definición de la interface donde por contrato haces que un método solo pueda leer y el otro sólo escribir. Realmente podrías simplemente poner que ambos reciben un canal del mismo tipo, pero queda más claro al leer si ves que uno solo necesita leer y el otro sólo escribir. Así que lo resumiría a ayudar en la legibilidad.

1 1 respuesta
Kaledros
#2radykal:

el otro sólo escribir

¿Y para qué necesitas un canal de sólo escritura si no puedes leer los valores que le pasas?

radykal

Sí puedes, pero no siguiendo tu ejemplo en el que directamente solo puedes devolver ese concreto. Digamos que creas un canal en un punto de la app y ese canal lo pasarás de solo lectura a un método y de sólo escritura a otro método. En tu ejemplo, que sólo lo devuelves como de solo lectura no sirve para nada.

EDIT con un ejemplo:

package main

import (
	"errors"
	"fmt"
	"sync"
)

func main() {
	errChan := make(chan error)
	wg := sync.WaitGroup{}
	wg.Add(1)
	go func() {
		defer wg.Done()
		handleErrors(errChan)
	}()
	doWork(errChan)
	wg.Wait()
}

func handleErrors(errChan <-chan error) {
	for err := range errChan {
		fmt.Println(err.Error())
	}
}

func doWork(errChan chan<- error) {
	for i := 0; i < 5; i++ {
		errChan <- errors.New("error")
	}
	close(errChan)
}

https://go.dev/play/p/VsLwckFwjxO

1 1 respuesta
Kaledros
#4radykal:

Digamos que creas un canal en un punto de la app y ese canal lo pasarás de solo lectura a un método y de sólo escritura a otro método

Aaaaahmigo, haber dicho barranquito XD Vale, ahora ya lo entiendo. Además acabo de comprobar que si intentas leer de errChan dentro de doWork() te suelta un error de compilación, entiendo que por detrás te está convirtiendo errChan a un canal de sólo lectura dentro del scope.

Lo que estoy intentando es pasar errChan a doWork por referencia y me dice que no puedo pasar un chan como parámetro porque cannot use errChanPointer (variable of type *chan error) as chan<- error value in argument to doWork, ¿lo estoy haciendo mal o realmente no se puede hacer?

radykal

Los chan se pasan implícitamente como referencia https://go.dev/doc/effective_go#channels

1 respuesta
Kaledros

#6 Tiene sentido, porque castear un channel a channel direccional da error. ¡Gracias!

pamplino

la diferencia entre server y client components en nextjs (llevo poniendo "use client" cuando typescript se queja hasta ahora pero no tengo ni zorra de lo que hace) y cuanto engordaría el billing de vercel al usar o no usar estos componentes

1 respuesta
S

#8 https://nextjs.org/learn/dashboard-app

Haz este tutorial, pasan bien por todos los puntos de Next

Zh3RoX

Pregunta.

Estoy haciendo un proyecto de prueba, total que procedo a crear el repo de Github para ir haciendo commits. Pues hago todos los pasos, git init, git remote, git add ., git commit y git push.

El caso es que si yo tengo el proyecto con esta estructura: nombreproyecto>part1>node_modules/src/public etc y hago el commit en este directorio nombreproyecto> , a priori se hace correctamente el proceso, pero una vez dentro de Github no me deja acceder a ver el contenido de esa carpeta.

Sin embargo, luego creo otro proyecto en nombreproyecto>part2 y hago el mismo proceso desde nombreproyecto> y si puedo acceder al contenido desde Github.

Que estoy haciendo mal? Seguro que es una tontería pero no caigo. De hecho creo que directamente está vacía esa carpeta pero no entiendo por qué.

3 respuestas
LR

#10 Hablando un poco desde la barra del bar ya que aun no le he dado en condiciones a git......puede que sea porque el repo lo tienes inicializado en ese nivel y no en el anterior?

1 respuesta
Zh3RoX

#11 Es una posibilidad sin duda, pero no tendría sentido en este caso. Quiero decir:

Si yo tuviese inicializado git en nombreproyecto>part1 al hacer el commit en nombreproyecto no me debería dejar hacer nada, y en el caso de que hiciese el commit dentro de part1, me debería dejar subir los cambios de todo lo que contenga ese directorio, es decir, solo la part1.

En cambio, si tengo inicializado git en nombreproyecto>, lo cual es el caso y hago ahí el commit, debería subir los cambios de todo el contenido de ese directorio, es decir, tanto la part1 como la part2, y en este caso se sube la part2 pero la parte1 no.

No sé si me he explicado pero es obvio que algo hago mal.

1 respuesta
beltez

#10 huele a que lo que has subido es alguna especie de acceso directo / enlace simbólico a tu proyecto, no el proyecto en si

LR

#12 pregunta muy tonta.... has mirado que no la tengas excluida en el gitignore?

1 respuesta
aren-pulid0

El node modules lo tienes en el gitignore y por eso no se sube a GitHub. NO hagas código en los node modules

1 respuesta
Zh3RoX

#14 No lo había mirado pero no, no es el caso.

#15 Obvio que el node_modules lo tengo en el gitignore, pesa mucho y no me vale de nada subirlo, ese no es el motivo porque la parte 2 también tiene su node_modules propio ignorado en el gitignore y se sube perfectamente.

Me raya la M esa que tiene los dos .jsx de la part1, creo que está dando conflictos de alguna manera con la integración de git de vscode, que no estoy utilizando.

1 respuesta
S

#10 creo que te está metiendo part1 como un submodulo, pega si eso todos los comandos que haces a ver si vemos algo

#16 la M es que tiene cambios creo y es azul porque está sin guardar el fichero

1 respuesta
Zh3RoX

#17
git init
git remote add origin urldelrepo
git add .
git commit -m 'comentario'
git push -u origin master.

Estos son los comandos que utilizo.

Aunque aún no lo he solucionado creo que el error está en que tengo dos repos inicializados a la vez y están entrando en conflicto.

2 respuestas
pantocreitor

#18 si has hecho un npm init dentro de las carpetas borra el .git y el gitignore de dentro y prueba a hacer git add —all desde el root del proyecto, a ver si así lo pilla bien.

S

#18 tiene toda la pinta, si le haces un

ls -a

tanto en la carpeta root, como en part y part2 puede ser que veas varias carpetas .git, borra todas menos la del root

1 respuesta
Zh3RoX

Al final me cargué el repo entero y lo volví a hacer todo de 0. Ya si he conseguido subirlo correctamente, es cuestión de tiempo que me surja otro problema con Git.

1 respuesta
S

#21 como critica, si estás aprendiendo, yo hubiera perdido algo de tiempo en entender que estaba pasando, siento esto como una oportunidad perdida de aprender algo

1 respuesta
Zh3RoX

#22 Realmente Git como tal no estoy aprendiendo aunque llevaba mucho tiempo sin usarlo y lo tenía oxidado, si es cierto que no manejo tanto situaciones más complejas con ramas y demás.

Le he dedicado bastante tiempo a entender por qué fallaba, buscando información, probando soluciones que me proporcionaba chatgpt y no me merecía la pena perder más tiempo en eso.

Entiendo tu crítica y la comparto.

1 1 respuesta
S

#23 yo he estado probando y para reproducir puedo reproducir el problema cuando tienes git inicializado en las subcarpetas:

.
├── .git
├── file1
└── part1
    ├── .git
    └── file2

Por si sirve de algo...

2 respuestas
Zh3RoX

#24 Sí, tiene sentido que fuera ese el problema pero cuando me comentaste en #20 que le hiciese un ls -a a los directorios para mirar donde había .git, lo hice y solo tenía un .git en la carpeta root, así que no le veía sentido a que fallara. En fin cosas del software.

1
Matamoross

#24 El símbolo de la flecha en la carpeta es para git submodules, básicamente incluir otro repositorio en el tuyo.

Usuarios habituales