cdeutsch

I can relate.

Every time I pickup an old iOS device the stupid thing is nags me to update it, 100 times. And you can't just click no you have to click multiple things to get it to fuck off.

Even better, electric bicycles.

Take all the transportation conveniences a regular bike can without getting sweaty.

One feature that would help a ton, that would hopefully be low hanging is to refresh the "Issues", "Merge Requests", and "To Do" count indicators in the background.

They're basically useless right now because I constantly have 6+ tabs open and they all have different numbers and I just now I need to do a full page refresh to get the updated number.

Ruby on Rails is opinionated. JavaScript is the exact opposite.

The data access layer in JS leaves a lot to be desired (especially compared to Rails)

React almost felt like a winner for single page apps, but there was never a great "flux" pattern to use, and now they've completely ruined that ecosystem with Hooks.

Also SPA's have become so big and bloated it's time to go back to something that you can build progressive web apps with like jQuery.

You should try out the Investopedia newsletter. https://link.investopedia.com/forward/5d121631cac67b640d47dc...

I like it a lot more than The Morning Brew.

The Morning Brew's jokes get too obscure and make it hard to read.

Caleb does a much better job than the Brew IMO.

Nailed it!

I've been programming professionally for 20 years and doing exclusively frontend with React since about 2014.

After the whole React Hooks thing, I can't freaking wait to do something else; and I'm absolutely livid with their decision to promote Hooks.

They should have forked React instead of introducing that into a somewhat mature ecosystem. Already went through this fractured bullshit with Coffeescript, and a million other frameworks of the moment. The JS community just doesn't learn, and when you see a big player like Facebook making the same mistakes, there really isn't much hope.

Don't let SnapChat make you feel like you're old.

It's a crap UI.

Exactly the reason I watch most Joe Rogan content as "highlight clips" on YouTube.

I don't have time for most of this drawn out content.

(I did listen to the entire Joe Rogan - Snowden podcast but that was a first)

Be ready for a career change.

Within 2 years, the vast majority of the ~300 person startup I worked for had found new jobs, and if they are still there they're likely not in the same role.

You could try a cloud based solution like https://curlhub.io/

Make sure you do your speedtest to a server beyond CenturyLink.

My speeds were about that to the CenturyLink data center, but anything outside that was slower than Comcast 150 Mbps.

Which leads me to believe they don't have a fat enough pipe to the internet in my area.

Which was too bad, because the $60/mo price was a deal

> Personally, the first month or so that I used hooks in react, it wasn’t pleasant

I didn't feel that want when picking up React originally, but I do with Hooks. That's a giant red flag in my opinion.

- Living in the city instead of the suburbs.

- Living in an apartment/condo; instead of owning a big, stupid house.

I used to think like that, until I was forced to use TypeScript at a new company.

Now I avoid using regular JavaScript.

I'm impressed how many bugs it prevents, and it prevents them early.

Refactoring in TypeScript is literally magnitudes easier and quicker.

Ada was the first language I learned at the University of North Dakota's Computer Science program in 1996.

Since the university is known for its Areospace program, I guess that made sense to pick Ada as their primary language.

I created CurlHub as a replacement for the original Runscope traffic inspector, which I loved, but is no longer available.

The biggest difference between the CurlHub and Runscope traffic inspectors, is that CurlHub saves the requests to your browser's localstorage, where Runscope saved them in one of their databases.

This means for CurlHub to log your requests, your browser has to be open.

The decision was made to use localstorage, due to GDPR. Storing random API response data, was not something I wanted to deal with.

You route all API requests through the proxy server.

So, say your API is `api.company.com`.

Instead of sending requests to `api.company.com`, you send them to `api-company-com-<BUCKET_NAME>.curlhub.io`.

That's all you have to do. CurlHub will proxy your request to `api.company.com` for you.

As long as your api server is public, and there is a configuration option to change the base domain of the API, it makes it super easy to inspect API requests.

What book are you referring to? Sounds good :)

Thanks. I'd love to make one for the desktop App but I haven't figured out a way to do more then Previous, Next, etc. No searching.

I've contemplated building my own desktop app though that basically embeds a browser plus the extension.

So there's multiple tiers being used in the demo. Nodeler itself is just for Node A finding Node B. Developers are free to define their own protocols to communicate between Nodes.

An add-on for developers will be the "Nodeler Central" communication servers which uses Node.js to accept web socket or tcp socket connections to create real-time communication between Nodes. This is what the demo apps are using.

Pretty much everything so far is javascript and C#.

More about the technologies is covered towards the bottom of this blog post: http://blog.cdeutsch.com/2011/05/introducing-nodeler.html

Nodeler is a zero configuration service (Apple calls theirs Bonjour) for web and mobile applications. It can be used to pair two applications/devices together in an easy and secure manner.

I'll be opening the API to developers along with posting sample code for using it, including the code for the Chrome extensions.

Ideas on how to use: -Instead of a mobile version of your site, create a "Full Screen / Media Center" version with remote control. -Use a mobile phone to control a game or app running on an iPad.

Direct link to Nodeler if you want to skip the blog intro: http://nodeler.com/

Donated! Trumpet Winsock was the gateway to my first internet experience. Thanks Peter!

Would love to see someone explain what this library does in simpler terms. I can't tell which terms are buzzwords, which are industry standard, and which terms are from their own internal vocabulary. PubSub? PubSub to what? Can you give some real world examples of when to use this library and what problems it solves.

Cost/benefit. We outsource encoding to Zencoder which costs $.02 to $.05 per minute. Then there is also the price of disk space and the amount of time it takes for the video(s) to be available. Maybe one day the cost/benefit will change.

It's priced $.02 to $.05 per minute so depends on how long the content you have is. We have lots of training and event content which is typically longer then a YouTube clip.

I care because I like Chrome and was enjoying using it to play H.264 video. I may switch to Safari.

I also care because I was very excited about the near ubiquity a video codec had finally reached in 2010. I don't want to go back to encoding for multiple formats (I hate you 3GP). I won't encode multiple formats until I have to, but the transition to a new standard is always painful and time consuming. If WebM "wins" I get to re-encode thousands of videos and since we now outsource that to Zencoder that means thousands of dollars to do so.

I'll repeat my question, which browsers stopped rendering GIFs when it became an issue?

I'm all for WebM. Let me know when consumers can use it and until then it's in your user's best interest to support H.264 because that's what the content I want to watch today is encoded in.

No, but Apple is the biggest factor. I'm willing to bet more corporate decision makers have iPhone's than Androids (which also don't support WebM by the way) and when you're selling a video hosting and asset management service that matters.

These are the other extremely popular devices that support H.264 and most will not be supporting WebM anytime soon so why would I encode in WebM until they do.

Android devices.

Sony PSP.

Sony Playstation 3.

Xbox 360.

Blackberrys.

Some Symbian Phones.

Windows Phone 7.

I'll jump on the WebM bandwagon as soon as more then 50% of the popular consumer devices support it. Taking away support for an established and popular codec just makes you an asshole and will be nothing more then an inconvenience as long as Flash player supports it and is included with Chrome.

Do you encode video for the web? Do you know how long it has taken to reach a point where there is almost a ubiquitous codec? I've been in the business for 10 years. Yesterday may have been the peak of ubiquity.

This is a selfish move by Google to put the screws to Apple. There's no question it's going to hurt users in the short term because they'll have to rely on Flash to playback H.264. And users are going to be using Flash a lot because the people like me who are in the business of encoding and hosting video will not be switching to WebM anytime soon. The millions of iOS devices and the higher ups who own them will dictate this for years to come. This is where your idealism meets reality.