<FromGitter>
<Blacksmoke16> i guess is there a more efficient way to handle this?
<FromGitter>
<mwlang> I've decided it's gotta be side effect of running in docker image. STD_ERR must be printing followed by a buffered STD_IN flushing and printing with the container exits.
<FromGitter>
<mwlang> oh, and @girng, math on strings idea comes from Ruby for me...but I think same exists in PHP and Perl, etc. (could be wrong about that)
<FromGitter>
<mwlang> The connection is not happening at point of the requires... I did a puts after every line and what ends up happening is error is printed first, always (except outside a docker container) and then everything I puts follows.
<FromGitter>
<girng> @Blacksmoke16 doesn't `>` move all that data through the console first, then to the file?
<FromGitter>
<girng> like, outputs it to the console first?
<FromGitter>
<girng> nvm, i'm not making sense
<FromGitter>
<mwlang> `>` in console is a redirect.
<FromGitter>
<girng> yeah
<FromGitter>
<girng> hmmmmm, iuno. we ned more crystal devs in here i cant help blacksmoke
<FromGitter>
<jaitaiwan> Hey guys, where can I find documentation about what the `*` means in function definitions like `Time.utc(*,...)`
<FromGitter>
<watzon> @mwlang I think you might be right lol
<FromGitter>
<mwlang> well, I'm just completely stumped at this point.
<FromGitter>
<mwlang> if I use a docker container's alias, like "db" then migrations can connect and run just fine, but the app cannot!
<FromGitter>
<mwlang> if I write a special purpose db.migrate script and add it to command line, migrator won't connect and do its thing until I use IP address instead of "db" alias for the container. command being ```/app/bin/db.migrate && /app/bin/maestro```
<FromGitter>
<mwlang> yank the first one and just have maestro running as command then must use "db" in the connect string, otherwise the app just exits, doing nothing (no error)
<FromGitter>
<mwlang> so it looks like for now, my quest for small docker image is pretty much dead-ended. The full image built does work! So I have no idea for now and will just live with that for a while and give my comfort/knowledge level a chance to do some catching up with both crystal and docker as language and deploy methodologies.
<FromGitter>
<mwlang> one last thing I tried was just doing migration always as part of the app starting up, but I reckon, still same problem. migration will only run if using IP address and when I do, then migration runs then app exits.... ⏎ ⏎ ``` code paste, see link``` [https://gitter.im/crystal-lang/crystal?at=5d22c6aa70baf3537d9ea905]
duane has quit [Ping timeout: 245 seconds]
<FromGitter>
<girng> hmmm
<FromGitter>
<girng> might need to reduce as much as possible and put all info in 1 post and post on forum or something
<FromGitter>
<girng> `_crystal_raises+43` is interesting as well
sorcus has joined #crystal-lang
<FromGitter>
<dscottboggs_gitlab> Oh, I think i had run out of RAM
absolutejam has quit [Quit: WeeChat 2.5]
absolutejam1 has quit [Quit: WeeChat 2.4]
duane has joined #crystal-lang
snsei__ has joined #crystal-lang
rohitpaulk has joined #crystal-lang
<FromGitter>
<mwlang> If anyone's interested in taking a peek at what I did manage to accomplish with my docker efforts, I've written up notes in the README and parked the app on github for all to see: https://github.com/mwlang/smallfoot
rohitpaulk has quit [Ping timeout: 258 seconds]
rohitpaulk has joined #crystal-lang
absolutejam has joined #crystal-lang
rohitpaulk has quit [Remote host closed the connection]
DTZUZO has quit [Ping timeout: 244 seconds]
<FromGitter>
<Blacksmoke16> any reasoning for including the migration in the same service the app is? did running it separately not work out?
<FromGitter>
<Blacksmoke16> i.e. make the class name include the module, vs opening the module then the class
<FromGitter>
<mwlang> number one reason I ditched the migrator image is because I couldn't control order of execution and the way I'm planning to use the project in production, I'll be spinning up lots of these in similar fashion to principles behind sharding for scaling purposes. So I'm always going to have trouble with that *first* ```docker-compose up``` command.
<FromGitter>
<Blacksmoke16> look into swarm
<FromGitter>
<Blacksmoke16> would handle that by waiting x seconds then restarting itself
<absolutejam>
I'd suggest against swarm tbh
<absolutejam>
it's dead in the water
<FromGitter>
<Blacksmoke16> kubernetes is another option
<FromGitter>
<Blacksmoke16> prob the better long term one
<absolutejam>
aye
<absolutejam>
and with the likes of k3s, it's easy enough to run even on client/edge machines
<absolutejam>
just a bigger beast and much more verbose
<absolutejam>
for migrations that require a live service, create a script that waits for a target first
<absolutejam>
eash enough to throw together in a bash s cript and you could even include in your main image, and just parse some env vars
<absolutejam>
or exec into a live container, if you're mutating a stateful component (eg. db schema)
<FromGitter>
<mwlang> @absoluejam why is swarm dead in the water? Are devops moving away from swarm to kubernetes?
Yxhuvud has quit [Read error: Connection reset by peer]
<FromGitter>
<mwlang> I thought about using shell script as mentioned in that last link @Blacksmoke16 shared (I read it too yesterday), but it just felt hacky and potentially brittle as well.
<absolutejam>
Might be a bit of hyperbole, but Kubernetes is pretty much the standard now
<absolutejam>
Docker Cloud is dead and the common platform is k8s. Even Docker (the company) support k8s commercially
<FromGitter>
<mwlang> I'm actually starting to study how both discourse and gitlab build out their docker images in their projects. I think I have a "school of thought" hurdle to climb over with my present thinking vs. what people do in practice.
<FromGitter>
<mwlang> k8s == Kubernetes?
<absolutejam>
I've tried Swarm and it felt unfinished and wouldn't scale much past dev. Now that there are micro Kubernetes OS and binaries, it's much more usable. We use kubernetes in prod and I wouldn't look elsewhere, but there is obviously a requirement of managing it (even when using SAAS)
<absolutejam>
yeah sorry
ht_ has joined #crystal-lang
<absolutejam>
k3s is a tiny binary that includes pretty much all of what you need to get started with Kubernetes and makes it hella easy to get playing locally. Much better than minikube (a VM approach)
<FromGitter>
<mwlang> I'll go read up on k8s. I got interested in it when it was first announced a couple years back, but never got around to biting the bullet to building docker images let alone moving any existing projects onto either docker or k8s.
<absolutejam>
we use compose in dev, but we heavily rely on CI to seed development images (including migrations) etc.
<absolutejam>
It's a big step and you can spend your time doing more ops than dev, meaning you spend a lot of time building systems insTead of actually writing code (I'm 'DevOps'; primarily Ops)
<FromGitter>
<mwlang> I maintain about 70 projects in production for various clients...but it's all been pretty stable with phusion passenger, nginx, and capistrano deploy scripts.
<FromGitter>
<mwlang> I believe it. I'm sure I consumed upwards of 40 hours just building docker containers since Thursday.
<absolutejam>
I feel like you definitely need to get into CI/CD early when using Docker or else you end up rangling images, configs & deployments more than actually deploying
<FromGitter>
<mwlang> but there's also the learning curve -- that's to be expected of any new initiative.
<absolutejam>
yeah, definitely
<FromGitter>
<mwlang> my mindset exactly. I want to get the basic core deployment and CI/CD infrastructure up now before I start building out the apps
<FromGitter>
<mwlang> big believer in getting small things working first that are also structured in the right way to extend itself down the road to what I know the project requirements are going to become.
<FromGitter>
<j8r> An advice: don't use your own K8S, specially in produciton
<absolutejam>
^
<absolutejam>
Managing the control plane is a job in itself
duane has joined #crystal-lang
<FromGitter>
<j8r> I prefer docker swarm or HashiCorp Packer, they are simpler while scaling as well as K8S.
<FromGitter>
<j8r> Not Packer, Nomad
<FromGitter>
<j8r> Packer is good too, Terraform a bit complicated at times
<absolutejam>
haven't tried tf since some of the new changes
<absolutejam>
like loops
<absolutejam>
bet it's more usable now
<absolutejam>
used to use it pretty religiously
<absolutejam>
along with Saltstack
<absolutejam>
I much prefer idempotence via. contains than mutating VMs and such though
<FromGitter>
<j8r> we use it with Ansible
<FromGitter>
<j8r> with the provisioner
<FromGitter>
<j8r> I'm working on https://github.com/DFabric/dppm and a REST API (more oriented on the client than enterprise for now), all in Crystal, because I think we have reached a point that there are too much abstractions on top of abstractions
<FromGitter>
<j8r> why we couldn't just have a good old baremetal host with binaries running in it? Instead of a machine with VMs with Docker containers used as K8S pods
<absolutejam>
eh, I'd prefer the opposite
<absolutejam>
containers provide virtual networking, process isolation, cgroups, a 'finished product' (image), automated builds, portability, scalability (via. commodity machines)
<absolutejam>
and we use Google Container Optimized OS which can't even run binaries in the persistent volumes
<FromGitter>
<j8r> nope
<FromGitter>
<j8r> your arguments doesn't necessarily need containers
<FromGitter>
<j8r> systemd can use cgroupsv2, statically linked binaries are portable
<absolutejam>
sure it doesn't, but it's been comoditized
<FromGitter>
<j8r> (openrc too)
<absolutejam>
and it's a single API to target
<absolutejam>
especially when using Kubernetes
<FromGitter>
<j8r> deploying a binary and using Nomad is much simpler
<FromGitter>
<j8r> architecturally, no networks inside networks inside etc... Hard to debug, and more possibilities of failures
<absolutejam>
I agree that bare metal and a binary is simpler that regards
Yxhuvud has joined #crystal-lang
<absolutejam>
less abstractions and indirections
<FromGitter>
<j8r> having an API is really nice for end user, i.e. developers
<FromGitter>
<j8r> problem is with K8S, basically, we have to pay $$$ for expertise
<absolutejam>
yeah, there's definitely an operations overhead
<absolutejam>
but you're also buying into a platform
<absolutejam>
we use a lot of kubernetes operators - and some inhouse written - which give us some great flexiblility, along with all of the service discover shenanigans
<absolutejam>
but it doesn't come for free - it's basically what I Spend my time doing
<FromGitter>
<naqvis> Confused about the `optional` or `Nillable` type use cases. Once defined as optional variable, why does compiler keep throwing error, even variable is initialized properly before invoking. ⏎ ⏎ Simple contrived example ⏎ ⏎ ``` code paste, see link``` [https://gitter.im/crystal-lang/crystal?at=5d23691a26a152537e4b831c]
ua_ has joined #crystal-lang
<FromGitter>
<j8r> you have to use a local variable
<FromGitter>
<naqvis> so question is what is the proper use case for `Nillable` types? Because it doesn’t make sense to initialize each and every variable in constructor
<FromGitter>
<j8r> yes
<FromGitter>
<j8r> you can see it as a safe `null`
<FromGitter>
<naqvis> my question is for instance variables
<FromGitter>
<j8r> you have to assign the ivar to a local one
<FromGitter>
<naqvis> yeah true, but that does clutter the code
<FromGitter>
<j8r> I think that's because it's shared by other methods, and may become Nil/not Nil if other code is executed simultaneously
ua has quit [Ping timeout: 244 seconds]
<FromGitter>
<j8r> you can use `@baz.try &.to_slice`
<FromGitter>
<naqvis> thanks @j8r
DTZUZO has joined #crystal-lang
DTZUZO has quit [Ping timeout: 244 seconds]
snsei__ has quit [Remote host closed the connection]
DTZUZO has joined #crystal-lang
DTZUZO has quit [Ping timeout: 244 seconds]
rohitpaulk has joined #crystal-lang
<FromGitter>
<dscottboggs_gitlab> I wish type restrictions were automatic for initializers ⏎ ⏎ ```class Klass ⏎ property @ivar : Type ⏎ def initialize(@ivar); end ⏎ end``` ⏎ ⏎ and get a nicer error and less chance of overload collision [https://gitter.im/crystal-lang/crystal?at=5d238f0772d4092b1aa9cf00]
<FromGitter>
<bew> You can do the other way around and put type restrictions in the initializer only
<FromGitter>
<bew> But I agree, wouod be nice and would make sense as well
<FromGitter>
<dscottboggs_gitlab> true
<FromGitter>
<dscottboggs_gitlab> I don't think the block variants of `property`, `getter`, and `setter` work without the types
rohitpaulk has quit [Remote host closed the connection]
ht_ has quit [Quit: ht_]
rohitpaulk has joined #crystal-lang
<FromGitter>
<mwlang> speaking of a somewhat "dead" forum...would anyone be interested in participating in a Crystal code refactor kata, each one run as a new topic/thread? Each person that tackles the kata can then post their experience and resulting refactored code.
<FromGitter>
<watzon> I feel like I know the answer to this, but I can't remember. Is there any way to have files be loaded at compile time? There is some data that I would like to have included in the compiled binary that is currently in a text file.
<FromGitter>
<girng> @Blacksmoke16 you ever figure out that ram thing?
<FromGitter>
<girng> @Blacksmoke16 oh just saw the forum post ,my bad
<FromGitter>
<dscottboggs_gitlab> @watzon yes you can read in a file at compile time
<FromGitter>
<Blacksmoke16> yea, ary gave some good ideas imma have to try out
<FromGitter>
<watzon> @dscottboggs_gitlab how do you go about doing that?
<FromGitter>
<Blacksmoke16> basically best to just pipe everything, or set a higher buffer on the IO::Memory if i cant
<FromGitter>
<dscottboggs_gitlab> checking the docs just a sec
<FromGitter>
<girng> @Blacksmoke16 that's what i wast aling about in ary's second listed point
<FromGitter>
<girng> but he explained it far better than me lolz
<FromGitter>
<Blacksmoke16> apparently so :P
<FromGitter>
<girng> i don't undrstand all this pull parser stuff. shouldn't the developer just be able to File.read over the file, loop through the data and then do what they want
<FromGitter>
<girng> can't File.read just be modified internally so it utilizes fibers/channels for extra performance. then just have it yield / assign a local variable toit when it's finished
<FromGitter>
<girng> then.. when MT gets added. File.read will be even faster
<FromGitter>
<watzon> Thanks @dscottboggs_gitlab
<FromGitter>
<mwlang> @girng You can indeed process that way. I did it myself when I first started Crystal and is definitely the fastest way to get going.
<FromGitter>
<mwlang> PullParser takes time to master, but doing so ends up making a lot of things easier in the long run.
DTZUZO has joined #crystal-lang
DTZUZO has quit [Ping timeout: 248 seconds]
<FromGitter>
<girng> nice, got selected to move forward to this "IT Technician" job at a library. wish me luck ;D
<FromGitter>
<girng> @mwlang yeah, i've never used pullparser before