Hacker Newsnew | past | comments | ask | show | jobs | submit | recurrie's commentslogin

Great video by Sam Chui about this posted a few days ago: https://youtu.be/csnaMnpU_BU?t=57


wow that _is_ great!


It's not that CRA doesn't cabbies to be contractors, its that they require all taxi drivers to register for and collect GST/HST- taxi industry does not qualify for the sub-$30K exemption. The reason for this was that otherwise, there were fears from full-time drivers that part-time drivers, making under $30K/year, would be favoured by customers over full-time drivers.

http://www.cra-arc.gc.ca/tx/bsnss/tpcs/gst-tps/txlmsn/menu-e...


That's fair, and definitely clarifies what the person I was replying to meant in a way that makes sense. Thanks.

I do think it was pretty unclear though if you go up the reply chain. :)


Graphic arts film wasn't at all fussy about the shade of blue (as you note) and so while there were expensive non-repro blue markers and pencils, everyone I knew (at the very end of the era of graphic arts cameras) used blue highlighters, so design studios were full of them.

I've stuck with blue as the only highlighter colour I'll ever use, more than 20 years since the original rationale.

Also, used to freak people out scribbling (non-repro) obscenities on a flat that was going to be sent to photo and turned into a newspaper the next day.


I've spent summers at my family cottage, looking across the water at Oak Island for 40 years, and am always interested when it comes up. I've been on Oak Island and the myth is 100x more interesting than what is there now, the rusting remains of recent exploration efforts.

So if a crew of pirates|Incas|freemasons|French Royalty spent the effort to dig elaborate tunnels and traps, where are the remains of their campsites? The middens? The cooking fires? All infrastructure to support a huge constriction project, all with hand tools?

Everywhere else from that era you find the garbage that gets left behind - ashes, clay pipes, lost tools, buttons.

These particular mysterious builders were not just super skilled, they were also the tidiest contractors known to history.

Sadly, the whole story is a mishmash of charlatans, myth, and a lot of basic geology. There's no mystery.


And mysteries only get better with age.


If you optimize for cars, you get cities optimized for cars.

Funny that it was a American (Christopher Alexander)who write the most concise recipe for getting this right in "A Pattern Language." Pattern 88, Street Café.

http://en.wikipedia.org/wiki/A_Pattern_Language

http://www.jacana.plus.com/pattern/P88.htm


Hype is amazing tool - only took a few minutes to get up to speed on it. We built an educational touchscreen kiosk in it, and then were able to deploy on an iPad by just scaling it down and downsampling the bitmap assets. A really polished tool.


Unless I've missed it, there isn't a way to cleanly add meta fields to the admin backend for products. It has to be done via an app, which means data entry needs to be split between built-in Shopify fields and meta fields via a Shopify app interface on a different screen.


I happened to be reading Make magazine's 3d printing guide, and I was struck the similarity to late 70s/early 80s personal computers. Lots of different technologies. Kits. (Mostly) terrible cases, even wooden ones. All sorts of "solution looking for problem" kinds of examples - 3d printing a coat hook is the "key all your recipes into a computer" of this decade.

To outsiders, 1970s computing looked like a bunch of kooky hobbyists, and it wasn't far off. I think in 10 or 20 years, 3d printing is going to be the solution to lots of problems we haven't considered yet.


The difference is that 3D printing is already 20 years old. It's maturing a bit more slowly than did software.


That's very misleading. In the late 1970s computers were already 30 years old.

Yes, the "PC" was new. And that's the whole point - we now have cheap (but rubbish) desktop 3D printers. It's the equivalent of the transition from mainframe to minicomputer to PC.


While you're right that both were old technologies. 3DP is noticeably slower in many variables. If we look at the "quality" of output from the mainframes -> Apple II, we see that the calculations would of course be the same and the programming largely the same - the discrete nature of programming being what it is.

However, the dimension of cost for 3DP (which is what the personal 3D printer movement is excited about) is only one dimension of many, and I'd argue not the biggest limitation.

3DP materials and process quality have certainly improved over time, but all of the current technologies are dead-ends in regards to competing with traditional processes - i.e. FDM/SLA/ProJet/PolyJet don't physically seem able, ever, to produce parts as nice as injection molding can for a myriad of reasons - even without cost as a concern. The situation for SLM/ProMetal processes is little better.

Perhaps the recent investment in 3DP will increase R&D spend on quality, but it doesn't seem to be the case if you look at the major or "maker" players.


CRTC Canadian content regulations don't apply to the internet.


Good call, I had no idea.

Looking into it, apparently the CRTC believes that internet audio and video broadcasting services are under its jurisdiction, but it has exempted all such services from regulation. The notice is at http://www.crtc.gc.ca/eng/archive/1999/PB99-197.htm.


Reframe the question: How would you get designers to start open source projects? The open source world is pretty much structured around serving the needs of those who can code.

In the field I work in, designers and developers have equal standing, and need to create a middle ground of shared workflow, technology and design processes that balance development and design.

In most open source projects, there are too many barriers to entry (real or perceived) for designers to see themselves as participants. Everything from version control systems that don't provide any real benefit for visual designers to project leaders that see design as "eye candy" all reduce the appeal to designers.

Remember, too, that designers have loads of options if they want to work for free. You know all those "Build a Facebook clone over the weekend, it will look great on your resume" jobs on Craigslist? Designers get that kind of pitch ("Design us something for free; it will look great in your portfolio") constantly. Open source projects looking to recruit designers need convey some tangible benefit to participating.

In the design world, peer recognition doesn't come out of working on open source projects that their designer colleagues have never heard of. Every designer I know of will jump at the opportunity to do really great work, for free if necessary. Looking at the open source projects I'm familiar with, few of these look like the kinds of places where a designer would expect to create really great work.


That's an interesting question. I also wonder how you would get designers to start open source projects without getting the opposite of a "developer-centric" project where developers are the second class citizens.

Can you (or others) elaborate a bit more on what a place where a designer could expect to create really great work would look like? Is it more of a personal aesthetic thing (something that is personally interesting)? Is it related to some of the other points in this thread (unfriendly tools, gruff face to the community, lack of control etc.)?


That a tough one - it's always easier to identify a problem than craft a solution. Here's a shot:

* Projects should include screenshots or other visuals (no matter what their state of completion) on project pages. Browsing the usual Github page shows no visuals at all. Not every project is going to be heavily visually oriented, but most of the project pages I see look like a giant "Designers not wanted" sign.

* An environment where design can happen collaboratively. The "design thinking" ethos requires understanding what the problem is before trying to solve it. To really involve designers, some sort of sandbox where ideas can be expressed as something other than code, feature requests, bug fixes or "64x64px.png goes here." Would be ideal - a way to say "I see this working like this..." in a way a visual designer can express. Lots of discussion happens via chat, etc, but pretty hard to access if you're already feeling excluded.

* Something recognizable as a team structure. If projects need a designer, a project page noting an unfilled slot on the team would be ideal, along with some details. Icon designer? UX specialist? Copywriter? What do you need?

* Integrating rapid prototyping tools for design exploration. One of the tough tasks I find in interaction design is to get a feel for how a complex system is going to work without building it. I've see everything from Flash to Filemaker Pro used to build working models, to then be built out in another tool. Photoshop comps are great, but not a great way to simulate a lot of complex interaction models. If designers and developers are going to speak the same language, it's probably not going to be code.

I teach at a university of the visual arts, and I've often wondered about finding a way to engage students in open source projects, but to be honest, I've always been to fearful of what the outcome might be to really push this. My worry is that for a lot of developers, a logo and a few icons is all they are looking for. Fair enough, but not terribly attractive to the types of designers that projects really need.

Finally, designers need to understand what a big deal software is. You almost never see application design (web, desktop or mobile) represented in the big design award annuals, and the types of things that do get in tend to be gimmicky, Flash-driven web sites for consumer products.


Yeah, I know what you mean about solutions. Actually solving the problem at hand is a whole different world than finding the problem.

I know that I've been guilty of not making/updating screenshots very frequently - they tend to be a pain. Something to keep in mind for the future, though.

A collaborative design environment is a hard one. I've found it really useful for code in the past but as you said, that doesn't help a whole lot on the design front. The only practical thing I can think of at the moment is sending links to static images back and forth over chat, but that doesn't get over the barrier to entry on chat.

The only other things I can think of there would be screencasting (which usually costs money and tends to be a little more one-way) and VNC but that requires a lot more trust than I have for strangers (or than I would expect them to have for me).

Team structure might be a hard one. I can't speak for all developers but I generally don't like having a formal team structure if it can be avoided. Do you think that the role part is important or just discrete, specific tasks? If you were thinking of more of a control thing, that might be even harder. Unless I'm the only developer, I generally don't expect to have much control over a specific area. Then again, I also wouldn't expect people to be jerks and completely change something I did without at least talking about it first.

As far as rapid prototypes for web applications go, I LOVE wicket (http://wicket.apache.org/) because your templates are pretty much CSS and HTML (none of that pseudo-code in templates crap) and you have pretty much complete control over your javascript. You can mock up an entire site in HTML and only need minimal changes to get it working with backend code.

I don't have as much experience with desktop applications but I wonder if rough HTML/CSS might also work for the interactive parts. I'd have to think about that one and it might be an excuse to try mocking up a desktop app I've been thinking about.

I don't know if you'd be interested or if it would work, but I'd be up for at least talking about less uncertain ways to get your students involved in open source.

I have a couple of ideas for projects that I'd love to get design help on as long as I'm not completely left out of the design loop. Getting more people (and especially non-coders) involved in open source and helping in education would be bonuses.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: