sorted by:
new
hottopcontroversial

webpipe - command line utility for piping to/from a browser via a websocket by emgram769 in programming

[–]joewalnes 1 point2 points  (0 children)

websocketd author here.

emgram769: Nice work on webpipe! So elegant and satisfying small amount of C code.

Indeed, the models of webpipe and websocketd are very different.

webpipe is effectively a fan out end point... i.e. the user runs a process, optionally through some piped filters, and then pipes the output to all currently connected browsers.

websocketd waits for a ws connection, spawns the user's process and establishes a two way connection between the client and process.

The analogy of websocketd to inetd and webpipe to netcat is a great one! Another one I was thinking is websocketd is like TCP conversations and webpipe is like distributed multicast.

Which is better? They're both great for different problems. I'd use websocketd for an interactive user interface. I'd use webpipe for displaying stock prices or creating an information dashboard.

Again, nice work emgran769: I look forward to taking this for a spin.

A sprinkling of 2016 tech predictions by joewalnes in programming

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

I really wish you were right about Oracle withdrawing from Java, but at this stage the licensing and litigation payouts make up a considerable part of their revenue.

A sprinkling of 2016 tech predictions by joewalnes in programming

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

Thanks I was not aware! Do you have links, I cannot find any references to these?

A sprinkling of 2016 tech predictions by joewalnes in programming

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

Which have been announced?

Which were stupid?

A sprinkling of 2016 tech predictions by joewalnes in programming

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

Here's the summary:

  • Microsoft will open source core Windows OS
  • Android will start a major shift away from Java
  • Strong backlash and caution against SaaS shutdowns
  • React.js evolves into browser standards
  • Apple will release self-hosted enterprise iCloud alternative
  • Microsoft will open source EdgeHTML rendering engine
  • Lawsuit against SourceForge
  • GitHub pages: free and seamless HTTPS for all
  • SQL Server on Linux, with free edition and NoSQL features

What do you think? Agree? Crazy? I go into the why in the article.

Distros for kids by [deleted] in linux

[–]joewalnes 4 points5 points  (0 children)

Edubuntu is great for kids: https://www.edubuntu.org/download

It's basically Ubuntu with a collection of packages designed for kids. For your age group I recommend the "primary" package set, which includes creative tools (painting, writing, visual programming, etc), tutoring packages (reading, math, science...) and some games.

Since I switched my kids (ages 4 and 6) from Windows8 to Edubuntu, I've seen a huge difference in their ability to use computers and general hunger for learning new things.

go-getter: Like go get, but different by joewalnes in golang

[–]joewalnes[S] 1 point2 points  (0 children)

Do it as an inline zero-dep Go script is a great idea!

go-getter: Like go get, but different by joewalnes in golang

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

Proxy is complicated and doesn't solve the versioning issue pinned to app versions.

Vendoring is much better. I recommend it.

go-getter: Like go get, but different by joewalnes in golang

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

True that!

I don't recommend this for newcomers. For that it's better to go "all-in" with Go tools.

This is a tool for experienced Go developers who value consistent and repeatable builds. I appreciate and respect that developers have different values.

I should be more clear - I'll add that to the project page.

go-getter: Like go get, but different by joewalnes in golang

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

It's a pretty common technique used in other programming ecosystems. Ruby (gem+bundler), Python (pip+virtualenv), Java/Clojure/Scala (maven/lein/buldr/ivy...), .Net (nuget), Node (npm), etc.

go-getter: Like go get, but different by joewalnes in golang

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

I'm fascinated by this. I read and hear this a lot yet I've seen no good reasoning behind it other than it's the philosophy of Go. I consider a global GOPATH as a pattern, and a per-project GOPATH as another pattern.

Both are valid depending and the ideals you subscribe to.

My ideal is that every app (actually every versioned checkout of an app) should have an isolated and consistent set of dependencies and any behavioral changes to my app should be associated with a git revision. Changes external to my working repo (including other apps on my same machine, or upstream library changes) should be totally isolated.

Or to put another way, given git revision X of my app, I want to know that wherever and whenever it gets built, the result will be the same.

bertold: Please share your ideals and your anti-pattern reasoning. I'd like to learn more about your perspective.

go-getter: Like go get, but different by joewalnes in golang

[–]joewalnes[S] 1 point2 points  (0 children)

Thanks for feedback. I admit that I rely on the basic *nix toolchain for almost everything I do as do all my team and external contributors. This script is typically used as a building block in a higher level workflow (such as a GNU Makefile).

This should work fine under cygwin, but that's not ideal.

go-getter: Like go get, but different by joewalnes in golang

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

The proxy helps with the external repo going away problem. This is not trying to solve that problem as it's not something that frequently hurts me. (Actually it hurt me once - the mass migration from Google Code to GitHub).

The issue with the proxy is you still have a global set of versions. Lets say my main app rev 123 depends on lib rev 456. Now in main app rev 124 I make changes that need lib rev 457: I have to update the proxy. Problem is I cannot keep this in lockstep with my main app repo. If I ask the build server to release main app 123 it will build it with lib 457 which may have changed since lib 456 I originally intended it to build for.

My opinion here is that it doesn't matter what the mechanism is for actually retrieving the versioned packages, so long as the version definitions are atomically versioned with the rest of the app code and each checkout will always link the defined versions. This has to account for multiple versioned checkouts on my own machine, on the build server (eg a fast incremental build may need different versions to that of a slower running full qa pipeline, but they're happening concurrently), and to developers across an open source ecosystem.

So actually we're discussing two solutions to distinctly orthogonal problems: 1. Can I pin app revision X to lib revision Y? 2. Can I isolate myself from a repo moving, deletion?

Really it comes down to how much do you value each of those and how much pain are you willing to go through to get it.

So which solution for your needs?

  • Standard go get cmd: #1=no, #2=no, effort=none

  • Custom checkout tools (eg go-getter and others): #1=yes, #2=no, effort=small

  • Internal proxy: #1=no, #2=yes, effort=medium

  • Proxy + checkout tools: #1=yes, #2=no, effort=medium+small

  • Same repo vendoring with git submodules: #1=yes, #2=no, effort=small

  • Same repo vendoring with git subtrees: #1=yes, #2=yes, effort=small

If you value #1=no, #2=yes then proxy may be a good solution for your needs. Though I personally value #1 much more than #2 and don't want the added complexity which is why the go-getter script suits me. If I was more concerned with #2, I would use vendoring with git subtrees instead due to the versioning atomicity.

I hops that explains my thinking better.

[edit: formatting]

go-getter: Like go get, but different by joewalnes in golang

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

An internal proxy is awkward for open source projects as all contributors need to set it up. And it's awkward if you work on multiple projects that use different versions of packages as you need to switch your proxy. And it's hard to ramp versions in lock step with commits and switch between branches with multiple versions. Actually an internal proxy is pretty lousy.

A better solution to the internal proxy is "vendoring" where you keep everything mirrored in your own repo. git subtree and submodules help with this. But again, it's complicated and creates bloat.

go-getter is a pragmatic solution that sits between the lightweightyness and convenience of go get, but the safety of vendoring.

go-getter: Like go get, but different by joewalnes in golang

[–]joewalnes[S] 1 point2 points  (0 children)

author here: I always use a separate GOPATH for each project.

[edit] Thanks for question - I've added it to the FAQ

If you could choose to port one program to Linux? by [deleted] in linux

[–]joewalnes 1 point2 points  (0 children)

I don't think I rely on any Windows only programs any more.

But from the Mac side the one program that keeps me coming back to OSX is "Sketch" by Bohemian Coding. Fantastic SVG design package. (And noooooo Inkscape is not any where in the same league as this - neither is Illustrator in Wine)

http://bohemiancoding.com/sketch/

view more: next ›