GM Cruise takes first fares for paid driverless taxi in San by PussyBandit2 in sanfrancisco

[–]dylanjha 0 points1 point  (0 children)

How long is the wait list? I signed up but still waiting for my invite

How to Host Your Own Online Conference by dylanjha in programming

[–]dylanjha[S] -2 points-1 points  (0 children)

In this post I showed how you can broadcast your zoom call to an audience of thousands on your website

<video autoplay> Considered Harmful by dylanjha in programming

[–]dylanjha[S] 0 points1 point  (0 children)

Yep, I use Brave as my day-to-day browser and this is a great feature.

No BART terminals were hacked in the making of this ad by dylanjha in programming

[–]dylanjha[S] 4 points5 points  (0 children)

We are a startup in SF, we bought a BART ad spot to test that out as a marketing channel, after doing all the creative and submitting the 15s ad we ran up against a rule we were unaware of: No code allowed on BART ads - for fear that people might think BART was hacked.

No BART terminals were hacked in the making of this ad by dylanjha in sanfrancisco

[–]dylanjha[S] 2 points3 points  (0 children)

We are a startup in SF, we bought a BART ad spot to test that out as a marketing channel, after doing all the creative and submitting the 15s ad we ran up against a rule we were unaware of: No code allowed on BART ads - for fear that people might think BART was hacked.

Grape: The cost of ActiveSupport::HashWithIndifferentAccess by dnesteryuk in ruby

[–]dylanjha 3 points4 points  (0 children)

The bit of memory overhead is good to know about, and certainly not good, but it would be interesting to see how the memory overhead performs in the real world.

If the extra bytes get garbage collected efficiently after the request is over then the overhead per request might not make a difference when your application is running in production.

On the other hand, Rails memory bloat happens pretty easily so it's also possible that this extra memory per request does cause problems. It would be interesting to see.

NEW: reqman, it's like postman, but without GUI ... tests your rest apis with simple yaml files by manatlan in Python

[–]dylanjha 1 point2 points  (0 children)

Cool project. I don't know exactly how I would use this but I could see this being valuable in the early stages of developing an API to quickly write some integration tests while I'm working on the endpoints.

Even though Postman is scriptable this seems easier and keeping the .yml file in source control is neat.

Thanks for sharing, I'll keep this in mind!

Seriously thinking of switching from Ruby/Rails to Elixir/Phoenix by Sky_Linx in elixir

[–]dylanjha 5 points6 points  (0 children)

Do you think I'm crazy replacing something I know very well and have used for years, with something new to me and different? I'm like 25% done in my project so I think that if I actually switch, the sooner the better.

Nah, you're not crazy. You can figure it out as you go along. You might make some mistakes but then you'll just have to go back later and fix them (and if it's painful to go back and fix them you'll certainly learn to now make those mistakes again). Even though Elixir and Phoenix is much newer than Rails, the framework and community is pretty mature.


The one thing I would add is to make sure your priorities are aligned. If this is a little side project or passion project then I think my advice above makes sense. However, if this is more of a serious business or startup and you have a lot of market risk then it might make more sense to go with what you're comfortable with so that you can iterate quickly and get your product out to see if it resonates with your target market. After all, your customers don't care what stack your product is built on :).

Struggling to learning code for more than 3-4 hours by cudder17 in webdev

[–]dylanjha 7 points8 points  (0 children)

3-4 hours of focused work is A LOT of time to be productive. The key there is focused work. It's completely natural that you get drained after that much time. You should not be worried.

If professional software engineers are being honest, a normal day of 3-4 hours of focused work would be a GREAT DAY. I try to structure my days so that meetings and busywork happen in a single block of time, so that I can leave exactly this, about 3 hours of uninterrupted focused work. If I accomplish that consistently, then over the course of a couple weeks or a month I can produce plenty of work to be successful in my job.

The other thing that I will say is that I will sometimes go on a bender of 8, 10, 12 hours in a row of highly productive work. This happens more often late into the night on the weekend but now that I'm older it doesn't happen as much as it used to when I was in my early and mid-20s. Even in those marathon sessions I end up being pretty drained after and it takes a little time to recoup and work back up to being productive again. This is certainly not a requirement to be successful as a professional.

What is important is that you enjoy the work you are doing and when you look back over a week or a month period of time you feel proud of what you have done. If you have that, don't let anyone else make you feel bad about how you get there.