timmy-turner's comments

Never having used C# myself but I sometimes play https://github.com/OpenRA/OpenRA (an open source Command & Conquer clone) which is written in C#, runs on all major OSes and uses Mono at least on Linux.

I tried mytaxi during a vacation in Italy. Went through the whole onboarding, including checking the trips expected fare and entering CC details only to get told after pressing the 'call taxi now' button by a popup that the service is not available in this area. WTF? Also the whole app looked very cheap and felt fragile.

In my hometown I'm just calling taxis off the street or via plain old phone.

Well, comparing these two countries infrastructure-wise to a software project, then China is a greenfield project which is able to pick whatever is the hippest technology at the moment because its still growing whereas Germany is the years old legacy Java project on its fourth partial rewrite that everyone relies on every day. And by everyone I mean people from those living on welfare to the billionaires at the top, not just upper class members or those belonging to the ruling party.

I'll bet that those failed projects would not have been called a failure in China.

Right, just using the plain gmaps tiles in a Leaflet tile layer is against the google TOS. But there is a Leaflet plugin that puts the whole google map component in a TOS-compliant way as a layer into leaflet and keeps both in sync with DOM observers. Sounds pretty weird but works perfectly in production.

https://gitlab.com/IvanSanchez/Leaflet.GridLayer.GoogleMutan...

I wonder which technology they are using to remove the silicon and metal films from the glass. Two guys that used to work in the same shared office space had developed a process to do exactly that. They stumbled opon it while experimenting with extremely bright and powerfull UV flash lights (couple of kilowatts for the fraction of a second). These powerful UV-bursts then remove films from surfaces due to the tensions introduced by the sudden heating. Building the first prototype in one of the guys basement involved some insane EE-hacking on their part such as manufacturing flash tubes to their own specs and building high voltage transformers to drive the flash tubes.

Last info I had was that they got founded and are trying to scale their process, opening a small experimental plant.

The only alternative to their technology that I know of is either throwing away the glass or melting everything and then recoup all elements. The former produces lots of waste and the latter needs huge amounts of energy.

Right, being able to compose, test, structure and develop my HTML in the same way I'm doing it with my application code is for me the main Reason for never wanting to go back to anything that's based on classic string-like templating. The latter always felt as clunky as programming without a proper function abstraction.

I'd probably make your work visible by counting the hours spent in the review each day or week. If you are able to roughly calculate the costs associated with those reviews, you may be able to push your organization towards adopting better coding or testing standards. Alternatively, instead of reviewing the code and pointing out the bugs, suggest or write a few tests which will uncover those. Showing good test coverage in action may be better than just preaching it.

No, I think integrating the web stack in a terminal is one of the better options. You'll get a lot of nice things that already work, e.g. serialization (HTML/CSS/JS/JSON), debugging (webkit dev tools, if you use webkit to render you terminal), libraries that are useful for terminal based apps (d3.js) and nice font rendering to only name a few.

`cat 50mbfile` will not halt a web based terminal if you don't keep it all in the scrollback buffer.

And you hopefully have learnt from the mistakes Powerbuilder did back in '95, not making them again. So in theory you're ahead of the crowd of today.

Though that means that you have acknowledge that things were not all that great back then as you remember - which seems to get harder as one grows older.

A terminal emulator - https://github.com/hoeck/schirm - using a browser to render the screen, allowing programs to use HTML and Javascript as an alternative output (via a CGI like interface).

Also, railways are not really meant to be safe against attackers with physical access to it (so basically anyone). For example, the sensors/switches on a railway that cause a train to perform an emergency halt if the train driver misses a stop signal can be modified by anyone near it - no encryption, no locks (source: https://www.youtube.com/watch?v=xwaKYZfgY8k - only in German though).

You don't even need explosives, a simple wedge welded on a rail would be enough. In the end, I don't think it is economically feasible to secure a railway against that (as well as any other kind of track). You have to make sure that nobody does stupid things like these.

Just reinventing the wheel to not having to use Powerbuiler makes a lot of sense to me. Even if it takes 20 years. Even if it only covers the trivial features. 5 years ago, I used to work on two huge Powerbuilder projects. I don't remember having real models or support for them in Powerbuilder and these projects. Everything was just datawindows, embedded SQL and stored procedures. I'm really glad that I'm now working on a web application at a different company.

There could also be an option to provide the app with fake data instead of telling it to not have any permissions, e.g. an empty address book, empty list of currently running apps, a fake network access which actually routes the data through a proxy and so on.

Shameless self plug: https://github.com/hoeck/schirm. It does exactly that, rendering arbitary html (inside iframes) between lines of a vt100 compatible terminal emulator, using escape-sequences to denote document data and images. Works quite well as a proof of concept. What annoys me so far is that its relatively slow (running find on a large dir may take ~20 times longer than on gnome-terminal) and the headaches around (automatically) resizing iframes.

No you're not the only one. I've been working on pretty printers for SQL and Clojure, to render their textual representation using html elements other than <pre> so that they keep their indentation, regardless of font style or size (example: http://pastehtml.com/view/bun1zr4o7.html).

Great to see another clojure tool heading away from the old traditional and largely text based environments to something new and better. Anyhow, looks a lot like Code-Bubbles to me (http://www.andrewbragdon.com/codebubbles_site.asp). As he was talking about how other engineers work, on big tables where they place and organize all their current notes, items, documents - in the future, I'd like to have a large epaper covered, touch and object sensitive desk and couple of light epaper devices to take down and organize notes and code. Software will become more complicated in the future, so I think at some day we will need to adapt and use more powerful tools than the ones we currently have.

Isn't this the fault of a bad UI mixed with bad defaults? I'm using the Cookieculler FF addon (https://addons.mozilla.org/en-US/firefox/addon/cookieculler/) to manage them. Instead of torturing me with a modal popup for every new site I visit, it keeps a list of hosts and cookies and trust status in the background. Using that list to protect important but delete/block all other cookies is quite convenient.

> Consider the transformations you might do on a piece of source code while you're playing around. A lot of these (for me, anyway) are things which change not just position or name, but the part-of-speech of words, or temporarily make a nonsensical expression. (I do it in my shell a lot, too.) Rigid structure-enforcing editors hinder this.

I hope that this can be mitigated by using an incremental parser (pretty easy to write for a lisp), which gracefully switches to a plaintext representation if the underlying code cannot be parsed anymore. The advantages of an editor which understands the code (both, syntax and simple semantics) you are writing or reading are just too promising.

Had exactly the same idea a few months ago, which resulted in 'Schirm': https://bitbucket.org/hoeck/schirm, screenshots: http://imgur.com/a/N84aw.

Its a VT100 (+colors) compatible terminal emulator (pyte) hacked to render into an HTML document, displayed using Webkit (pywebkitgtk). Currently requires python2.7, gtk, webkitgtk (only tested on Ubuntu 11.04 so far). Html output is done by using escape sequences to mark beginning and end of html strings or base64 encoded resources (js, images ...). You can even use js frameworks (used jQuery + d3.js to generate the circular tree in the 2nd screenshot). Communication between the terminal emulator and the client can be achieved by using console.log messages or some kind of HTTP (over stdin/stdout). Would love to get some feedback.

For those that can't wait for google, there are already some pretty mature browser-based terminals out there. For example shellinabox (https://code.google.com/p/shellinabox/) which is a full javascript implementation of a vt100 compatible terminal plus a server written in C providing pty streams over http. Web shell (http://code.google.com/p/web-shell/) is another one, doing all the terminal emulation on the server written in python and transferring full lines to the browser.

If you're interested to write your own terminal emulator, have look at pyte (https://github.com/selectel/pyte), a very clean and beautiful python library to write vtxxx compatible terminal emulators.