"Did you mean?" Experience in Ruby - <AUTHOR> http://www.yukinishijima.net/2014/10/21/did-you-mean-experience-in-ruby.html <comment><USER3> I've been pairing with ruby / rails developers since 2010 and coming from statically typed languages, it's unbelievable how much time gets spent playing "guess the method name". Even in rich IDEs like RubyMine, the utter lack of context in any given file in rails leaves programmers typing their best guess of a method name, running the tests, rinse, repeat.

This solution, while creative and laudable, solves a problem that shouldn't exist. It should either be solved by IDE/tooling in a dynamically typed language or by the compiler in a statically typed language. Stop guessing and let your tools do the hard work of remembering method names for you.

<comment><USER4> I have exactly this frustration as a person coming from static languages (mostly C++) to web dev. Anybody can recommend something more comfortable? I like the concept of Vaadin, but I'd prefer something non-Java.

<comment><USER5> Try Go. It is a lot like C and compiles to concurrent machine code. It is also very easy to learn and use.

<comment><USER6> Er, you mean to say "compiles to machine code." There is no such thing as concurrent machine code... Now the Go language has some fantastic data structures baked-into the syntax that provide a language with which to construct concurrent programs.

</comment></comment></comment></comment><comment><USER7> A lot of people are recommending IDE-like tooling--but in truly dynamic language (one with a "living image" with path-dependent monkey-patched behavior that can't be replicated during static analysis, like Smalltalk--or, sometimes, Ruby) there's a more idiomatic way.

In a dynamic language, if you're at all unsure of what code you need to write, then you _don 't write it in your editor in the first place._ Instead, you build the expression you need, interactively, at the REPL—and then, once it works, you paste that _into_ your editor.

In dynamic languages, the "dead" code in modules is effectively a coagulation of previously "live" REPL incantations; to trust code that was written "dead" to work correctly "live" is madness (or just a recipe for really long iterations involving unit tests.)

If you take this approach far enough, though, you do get a sort of IDE—something that manages your expression experiments and the context harnesses they need, and re-runs experiments when you edit their dependent formulae. I am, of course, talking about "notebook" interfaces like IPython's.

<comment><USER8> And with Ruby, especially since you mention Smalltalk, we have a tool that is getting _closer_ to the kind of live introspection and modification that Smalltalk is famous for: Pry [1].

Pry lets you call "binding.pry" anywhere in your program to dump you into a shell within that context, with full access to local variables etc.. And tab- completion and plenty of introspection features. I frequently find myself triggering Pry in the middle of handling http requests if something doesn't work, for example. Letting me inspect the environment, modify stuff, and when I exit the request is completed.

It can also do things (with some limitations) like bring up an editor to where the current method was defined, and let you edit and reload the code.

And you can attach to it remotely using Drb in case the app in question doesn't run attached to a terminal.

At this point it's almost criminal to do Ruby development without Pry.

[1] [http://pryrepl.org/](http://pryrepl.org/)

<comment><USER9> In pry is it possible to return something when I exit the REPL? Like this:

      def do_something
        return binding.pry

        do_something_but_does_not_work
      end

      result = do_something
      process result

It might be very convenient if I put 'return binging.pry' just before the broken code. I can interactively fix the broken code and continue run outside of current method.

<comment><USER8> If you are explicit: "return" in a Pry session will exit pry and return the value you pass to it, just as if you are in the method itself. So e.g. "return 42" would return 42 from do_something.

</comment></comment></comment></comment><comment><USER10> Neat. In case you're wondering, it's implemented using a levenshtein distance algorithm:

[https://www.omniref.com/ruby/gems/did_you_mean/0.6.0/symbols...](https://www.omniref.com/ruby/gems/did_you_mean/0.6.0/symbols/DidYouMean::MethodMatcher/similar_methods)

and it works by extending the NameError exception:

[https://www.omniref.com/ruby/gems/did_you_mean/0.6.0/files/l...](https://www.omniref.com/ruby/gems/did_you_mean/0.6.0/files/lib/did_you_mean/core_ext/name_error.rb)

<comment><USER11> The close_enough gem takes this one step further and uses this to 'patch' method_missing:

[http://decomplecting.org/blog/2013/03/01/code-typos-got- you-...](http://decomplecting.org/blog/2013/03/01/code-typos-got-you-down- stop-worrying-with-close-enough/)

</comment></comment><comment><USER12> Some years back I put this feature in both the Digital Mars C/C++ compiler and the D language compiler. It's turned out to be popular and very useful.

Compiler error messages are steadily improving from mere statements of what is wrong to suggestions for corrective action.

</comment><comment><USER13> Obviously this is a useful tool, and all the power to the author for finding what looks to be an excellent solution, but this line bothers me:

>>> Sometimes I wasted hours and hours just because there is one character difference. I hate it.

 _This shouldn 't happen._ Ever. This should not be a problem anymore. These are the sort of errors that we can catch immediately and should be caught immediately. From looking at the author's GitHub profile, it looks like he uses Emacs, presumably without a plugin that would give him IDE like features. I'm not going to tell him to go use a regular IDE, but it frustrates me that's we can't have those sort of tools available everywhere. (As a vim user myself I have high hopes for the neovim project and look forward to the day when it can be embedded inside a general sort of IDE.)

<comment><USER8> While you can catch _some_ of these, for a language like Ruby, it's an incredibly hard problem to catch all of these errors immediately because the methods that can be called on a given named entity _can not_ in the general case be known by statically inspecting the source, and you can not in general safely instantiate the application because even class definitions are _executed_ and can have side effects, and the methods available can even vary based on environmental factors, such as whether or not you get a database connection, and what's in the database.

Consider that it is a common pattern for Ruby ORM's to either use method_missing or dynamically define methods to correspond to the current (at connection time) set of columns present in your database.

And "thanks" to the ability to monkey patch and redefining methods, even determining if something "obviously" safe like 42.to_s is not.

There's no way for your editor to handle that unless you stand up a version of your app with an instrumented language environment and lets the editor poke around. Now _that_ is possible with tools like Pry, etc., but it takes a lot more work to do safely (because your editor can't know if it can safely start your app).

</comment></comment><comment><USER14> The value of static typing is more and more apparent. Recently I've played with ocaml and F# and it felt great compared to Java or C++.

<comment><USER15> ... until you start trying to make your app testable.

(I say this as a developer of primarily statically typed languages.)

<comment><USER16> Try using a good type-inferred statically-typed language. Hint: this rules out Java, C# etc.

</comment></comment></comment><comment><USER17> This sort of stuff should, at least in the 'easy' case be done at the editor level. Doesn't ruby have linter tooling for this?

Still, props for the work.

<comment><USER18> Ruby has a linters, but this sort of problem is hard to solve with a linter in a dynamically typed language. It's even harder in a Rails environment since Rails adds many methods to your classes at run time.

<comment><USER19> Yeah, since it's a dynamically typed lang with inheritance and late binding, doesn't performing static analysis on Ruby code to determine whether a method is defined or not, basically require a solution to the halting problem?

I'm under the impression that you have to actually execute Ruby code to find out with certainty where the methods it calls are defined.

<comment><USER8> You can solve the "90%" problem statically. My Ruby-compiler-in-progress warns of methods that have not been seen, and I may eventually add some (entirely optional) pragma to allow hinting to reduce false positives (though getting that non-intrusive will be a fun challenge).

But you are right, the general case does require a solution to the halting problem, something which is trivial to demonstrate very explicitly:

        eval(STDIN.gets)
        42.will_i_halt?

Put that in a file, and run it. Press enter, and it halts. Or cut and paste something like this, and it doesn't:

        class Fixnum; def will_i_halt?; loop {}; end; end

And consider that even "require" is a practical equivalent to "eval", so trying to look for eval() calls and similar constructs and think you're safe doesn't work, unless you have a guarantee that the interpreter load paths will be the same when the code is run as what you think it'll be.

But in more pragmatic terms, this is a real issue because many Ruby ORMs for example will add methods that depends on the current state of the databases they connect to, so many typical Ruby applications _will_ actually validly use method names that are not explicitly defined anywhere.

</comment></comment></comment></comment><comment><USER20> Blows my mind that IDEs and environments are not better at this. This is something that computers are good at, pattern recognition and scanning the whole file. Of course the it wouldn't work every time, an could make ridiculous suggestions, but I would love the computer to suggest something every time there is an issue. Even if it is wrong 90% of the time, if those guesses don't slow down the programmer the time saved would be huge.

<comment><USER21> Java IDEs are better at this. JavaScript...well I saw NetBeans do it once and was amazed. Ruby...well it's impossible to do correctly as other posters have mentioned.

</comment></comment><comment><USER22> I think this is an amazing gem. And I'm eager to use it on my Rails projects.

On a side note, am I the only one who feels that autocomplete tend to get in the way when I'm coding?

<comment><USER23> The trick is to actually use it. If you auto complete then your coding should be typing 2-3 characters, hit enter, 2-3 characters, enter and so on. It should feel like you're entering hotkeys not typing.

Only real typing should be defining variables and methods.

Your coding speed can go way up depending on how good the autocomplete is.

</comment></comment><comment><USER24> Or just use some semblance of static typing and completely eliminate this class of bug.

</comment><comment><USER25> > Sometimes I wasted hours and hours just becaue there is one charactor > difference. I hate it.

Haha, humans are much more able to parse meaning, despite a character being off here or there. Well, you've taken computers one step closer to humans. And you've made programming with Ruby friendlier. Great job!

<comment><USER26> When I read that line you quoted, I wondered "how did the author ever finish the gem, since it didn't exist yet to help them with their typos?"

</comment></comment><comment> ryan-allen It's almost like... statically typed languages!

</comment><comment><USER27> I see you used the Levenshtein algorithm to calculate the suggestions, very cool idea. I've noticed lately that it is being used quite more often than in the past. (may just be my perception)

</comment><comment><USER28> 'Sometimes I wasted hours and hours just becaue there is one charactor difference. I hate it.'

Not sure if the typos (Yeah, there are two) are intentional but I loved it :-)

<comment><USER29> > So what will happen when you misspell ActiveSupprt's > Hash#with_indifferent_access?

Turned down the too-obvious ironic opportunity and went for somewhere else in the sentence.

</comment></comment><comment><USER30> Not sure how helpful this is, when it says there's no method called xyz, it's pretty obvious you called the wrong method, or you called it on the wrong thing. Your first thing should be checking that you didn't call the wrong method name.. which involves looking at the error which repeats the method name that you tried to call, and the object you called it on.

Bizarre that this is a genuine hang-up for people.

</comment><comment><USER31> I use Rubymine, which visually indicates when a variable is unused or doesn't exist.

It has tons of other features that save you time and hassle.

<comment><USER32> RubyMine FTW. It's amazing to me how completely Dwarf Fortress -- um, I mean vim and tmux -- have conquered the Ruby dev world.

</comment></comment><comment><USER33> Could I also highly recommend making your project Rubocop-clean, and using pronto to run Rubocop on your CI server and make comments on your commits in Github. Rubocop warns against any methods you define that are not used at least once.

</comment><comment><USER34> I would love it if instead of quitting my program with an error, it just went ahead and called the method it thinks I'm referring to. This would remove a lot of unneeded friction from web development.

<comment><USER35> You should implement a `yolo` gem to support this.

<comment><USER36> [https://github.com/markburns/fuzzy](https://github.com/markburns/fuzzy)

</comment></comment></comment><comment><USER37> Who's gonna be the first person to hook this into method_missing()

</comment><comment><USER38> I hope somebody forks this and creates a version that automatically corrects the method for you at runtime. Why even show an error or throw an exception?

Bonus if the corrections are cached for performance.

<comment><USER39> What a horrible idea - what if the suggested method wasn't the intended one?

</comment></comment><comment><USER40> A python implementation of "Did you Mean?" by Peter Norvig [http://norvig.com/spell-correct.html](http://norvig.com/spell-correct.html)

</comment><comment><USER41> Strange. As an ruby programmer, I never had such a need.

</comment><comment><USER42> "Sometimes I wasted hours and hours just becaue there is one charactor difference." Oh thank God! I thought I was the only one.

</comment><comment><USER43> Wow. Talk about the wrong approach. When you're having to play trial-and-error to get the right method, you definitely have a problem with your tools - <USER2> the language!

I don't know about other editors, but vim has great autocomplete support for ruby built right in. Because of this I don't often even type methods out in full anymore.

And there's a great plugin for doco too: [https://github.com/danchoi/ri.vim](https://github.com/danchoi/ri.vim)

</comment><comment><USER44> > Here is a good exmaple...

Looks like "Did you mean" could be a nice extension to browser textboxes too. ;)

</comment><comment><USER45> This is really smart, really the sort of thing you wonder why no one thought of it before.

</comment><comment><USER46> Glorious Haskell Compiler suggests names for typos too.

</comment><comment><USER47> How about implementing this in a way that it starts guessing method names while typing a method?

In this case, you would solve the error while typing it.

A simple dropdown with suggestion(s) would be great in Sublime Text.

</comment><comment><USER48> "Did you mean?" is great, but "Do you mean?" would be better. Achieving latter in Ruby/JS/... certainly feels harder.

</comment><comment><USER49> >>> Sometimes I wasted hours and hours just becaue there is one charactor difference. I hate it.

"because" misspelt.

<comment><USER50> 'Charactor' is also miss-spelt... It's intentional.

</comment></comment><comment><USER51> Seems like a bandaid approach to fixing a severed artery. The real problem is the lack of desire to read documentation. This also has the problem of sending someone down the wrong path when the wrong "solution" is suggested. Read more documentation and pay attention while you're programming.

<comment><USER52> I don't think this has to do with a lack of knowledge of documentation, it has to do with simple spelling errors. Quite a number of times I type a method name wrong and upon scanning the code don't see the missing, duplicated, or mistyped letter. This would help a lot with that.</comment></comment>


What is the next big social network site trend? - <AUTHOR> http://codejustin.com/what-is-the-next-big-social-network-site-trend/

<comment><AUTHOR> What do you think the next big social networking trend is?</comment>


Ask HN: Why is IndieHackers website so slow? - <AUTHOR> My PC is pretty decent but that website just feels so slow and sometimes Firefox stops executing the scripts on it, why isn't it just like hackernews ? <comment><USER2> This is so random to be asked on HN! Why don't you ask the founder.

But to be true, I do not think IH is slow. If there are a lot of comments then it might take time to load.

</comment><comment><USER3> The app is written in Ember. Ember is slow with lists.

</comment><comment><USER4> I don't know but if I had to guess it seems to use ajax for everything. They should consider pre-rendering content.

</comment><comment><USER5> What are your suggestions in terms of low hanging fruits to make it fast?

</comment><comment><USER6> it is slow from Android also.</comment>


Exxon Knew about Climate Change Almost 40 Years Ago - <AUTHOR> http://www.scientificamerican.com/article/exxon-knew-about-climate-change-almost-40-years-ago/ <comment><USER2> Sometimes the conspiracy theorists are right.

</comment><comment><USER3> The anticlimate change lobby had its pockets sooooooo greased...</comment>


Google plays the long game with ChromeOS - <AUTHOR> http://www.theregister.co.uk/2012/01/25/google_chromeos_plans/ <comment><USER2> As they are saying, it seems that Google is just getting started.</comment>


The life and death of a laptop battery (2015) - <AUTHOR> http://people.skolelinux.org/pere/blog/The_life_and_death_of_a_laptop_battery.html <comment><USER2> > Is there a good and generic way with Linux to tell the battery to stop > charging at 80%

I wish every device with a lithium battery had this feature. Maybe I would still have a battery in my MBP today ...

I had to remove it since it was expanding and pushing the trackpad out of the chassis. Thankfully it was easy to do and the machine still works plugged into main.

<comment><USER3> In my experience, the damage of not stopping at 80% is minimal. Perhaps it is more related to the quality of the battery / hardware surrounding it?

I have not been particularly kind to my battery, but all the same my Samsung Ativ Book 9 Plus from 2012/2013 still has 83% capacity and can live for about 4-5 hours browsing/reading/programming.

<comment><USER4> I am not a battery expert, but my understanding is that the most significant way that batteries degrade is through the heat production when charging near capacity (say 80-100%). This is why high end laptops like macbooks or thinkpads have battery management hardware/software that never automatically charges the battery to 100%.

For instance, based on recommendations by TLP, my thinkpad internal battery only charges to 60% and external to 75%.

<comment><USER5> > This is why high end laptops like macbooks or thinkpads have battery > management hardware/software that never automatically charges the battery to > 100%.

Here:

> Software may limit charging above 80% when the recommended battery > temperatures are exceeded

[https://www.apple.com/ca/batteries/maximizing- performance/](https://www.apple.com/ca/batteries/maximizing-performance/)

I recall seeing another document on apple.com (that I can't find) that described the behaviour where leaving a macbook plugged continuously cycles between back and forth charge and discharge between something like 90-96% to avoid trickle charge and prevent wear due to heat.

Anecdata: my work laptop has been basically stationary and therefore plugged in for the best part of the last three years, and the battery is in outstanding condition. My personal one has been mobile more often but still plugged in for extended durations, and at four years old its battery is in a similarly awesome condition.

</comment></comment></comment></comment><comment><USER6> I'm a bit confused, I never had any battery die like that on me. I am currently using almost 5-year old T440s which has two batteries (internal and removable) and they are both still about 80% of their initial capacity. My laptop currently says it will last 8h on fully charged batteries which in my experience is fairly accurate.

I am using this laptop every day at work and at home. I am lugging it to every meeting, I am lounging on the sofa trying to get up to date with news and email. It has VMWare Workstation installed on it running at least one vm with Ubuntu at any point in time.

The ONLY two rules I follow is to 1) never allow battery to run very low and 2) make sure the laptop never uses a lot of power by trying to remove the culprit whenever fan starts to spin without apparent reason.

The laptop is on AC power as much as possible, whenever possible. I always alow it to charge to 100%. Whenever laptop is less than 100% I will make sure to connect it to AC as soon as practically possible.

Now, X230 is another premium laptop from Lenovo and it was debuted less than 2 years before T440s. It looks improbable to me that the difference in longevity can be attributed to some advancement made in that short time. I think taking good care of laptop (not letting it run hot or run out of juice completely) is much more significant effect here.

<comment><USER7> I think it really depends on how many cycles the batteries have gone through. You say you keep yours on AC most of the time so maybe that's why.

<comment><USER6> What I meant is that laptop spens large portion of the day discharging, doing work. But I rarely let it get below 50% which is when main 6 cell battery starts running out before switching to internal 3 cell one. I unfortunately don't record the usage of my battery but mine would be different from the author of the article. In mine, I guess, you would see say 80% of days not going below 60% of charge.

While I could technically last entire day on one charge bI never venture from home without charger and I always let it charge even if I have just few minutes between meetings. I also use the regular 65W charger to charge large battery which charges slowly (but I guess it helps maintain lower temperature).

<comment><USER7> Well if you only discharge it partially, that only counts as a partial cycle, which helps keep your battery good.

It's good to let it get completely flat every now and then, I believe...

</comment></comment></comment></comment><comment><USER8> For old macbook users (with magsafe connectors), covering the middle pin in connector stops charging the battery while running the laptop on main power supply.

Details: [https://apple.stackexchange.com/a/132332/87309](https://apple.stackexchange.com/a/132332/87309)

<comment><USER9> Sorry, why would I want that? Didn't they have smart overcharge protection yet?

<comment><USER8> Yes, they have over-charge protection. But apple laptops still go all the way to 100% whenever you plug in.

It is not a good idea to charge a lithium battery to 100% all the time. The source article also specifically mentions it, giving reference to Battery University.

</comment></comment></comment><comment><USER10> Some time ago, I stumbled upon a graph (sorry unable to retrieve its URL) showing correlation between the discharge depth of a battery and its lifetime in cycles.

Obviously, the less you discharge it, the longer it'll last. OTOH, the less you discharge it, the more you'll cycle it.

From data scraped from the graph, despite all of this is not linear, I found the best compromise was to not go lower than 50 % discharge.

I've been applying this discipline to my new notebook battery for 6 months and its full capacity is now at 95 % after almost daily use. And 3% on the lost 5% were after I ONLY ONCE let it go to full discharge.

<comment><USER11> _And 3% on the lost 5% were after I ONLY ONCE let it go to full discharge._

It is probable that what you saw was your capacity gauge calibrating to the actual capacity of the battery. The device doesn't actually know its capacity until it hits empty.

</comment></comment><comment><USER12> > Is there a good and generic way with Linux to tell the battery to stop > charging at 80%

There is, if your device contains a Texas Instruments charging chip. Many Laptops, not only Thinkpads, use them and they can be told a maximal charge voltage via SMBus.

You don't even need a kernel module for this, but its source might be a good starting point.

Please let me know if you write (or know of) a tool for this or need some help regarding SMBus/TI datasheets.

<comment><USER13> Hey, I would love to write a tool to manage this! Do you have any documentation on how to access the TI chip?

</comment></comment><comment><USER14> I thought the more important thing was not to _discharge_ your battery _too deeply_. It's especially bad to keep it at a very low state of charge for a long time (use the device until it dies and then not recharge it for a day or two). If you try to keep your battery charged to above 40%, its lifetime should be a lot longer. I also don't charge my ThinkPad to 100% (I limited it to 85% using tlp), but afaik that's not as important.

My iPhone 7 is now a little over two years old, and battery health reports that the maximum capacity is 90%. I use around 60% of charge every day, but I can count the number of times it went below 20% on my fingers.

</comment><comment> throwaw-zxcvbn Apple replaces a laptop battery for free under Apple Care if its capacity falls below 80% of design capacity.

(Note that it's measured using Apple's diagnostic tools, not using the value displayed in the System Report).

Assuming, hypothetically, that some selfish person were happy to get a new battery paid by Apple for their expensive laptop as it approaches the end of the AppleCare contract, but the diagnostic pegs it at over 80% - would it be possible to push it under 80% over a few months? How? (Not a question most articles on laptop batteries address, for some reason...)

<comment><USER15> I know when I was interested in a similar question several months ago, the advice I found was that laptop batteries like to stay at a higher charge level. Depleting the charge and allowing the cells to remain empty should damage the battery's capacity.

</comment></comment><comment><USER16> I find balloons to be a useful analogy when describing charge limits to users (and when configuring ThinkPads I limit the max charges). If you have a balloon and repeatedly inflate it to 100% then deflate it, at some point it's going to pop (or you're going to have to start putting less and less air in) due to the repeated stress and stretching. If instead you inflate it only to 80-90% you're avoiding that last extra bit of stretch and will likely get far more inflation cycles.

</comment><comment><USER17> this is actually a topic I took very seriously recently. I have a 1yr old Precision 5520, a great laptop made greater by the fact you can get it with a 9cell battery.

However I checked the status of that battery around six months ago and it had dropped to 91% of its initial capacity. Might not sound like a lot but it was only six months old and I upgraded the battery because I didn't want to worry about looking for an outlet during long flights/travel essentially.

So I looked into what makes l-ion batteries wear out and found that (unsurprisingly to many of you) batteries that are fully charged are under stress, and the heat of charging from 80%->100% is what causes harm also. The Dell BIOS allows you to set a maximum charge cap, actually they allow much more granular tuning too such as "office hours" where charging will be full speed but out of those hours the battery will trickle charge etc. However I was interested in setting a hard limit, since the bios is uefi; you are exposed to its settings in the OS (Linux in my case), I was wondering if there was any way to alter these values from inside the OS- so that I don't have to reboot to go into "road warrior" mode (and summarily charge my battery after rebooting of course).

Ideally I'd be able to manually trickle charge too to preserve the life of the battery;

Any ideas?

<comment><USER18> I don't know about Dell, but my Lenovo laptop has a tray icon where you can set a "Battery Miser" mode where it only charges the laptop to 80%.

I know some Dells have a function key that will tell the laptop to stop charging the battery, but that's pretty crude and manual. However, if you figure out what exactly that function key is doing you might be able to replicate it with a custom tray icon/system service.

</comment></comment><comment><USER19> Discussed at the time: [https://news.ycombinator.com/item?id=10276836](https://news.ycombinator.com/item?id=10276836)

</comment><comment><USER20> The battery of my old laptop (HP nc8430 2006-2014) went much like the one in the post.

The battery of the new one (HP ZBook 15 2014-now) looks still new. My usage pattern is almost all the time plugged into main, sleep during the night (charge goes down, especially after I upgraded from 16 to 32 GB), occasional battery only when at customer sites or traveling.

I run the script in the post (s/energy/charge/ on Ubuntu 16.04):

        timestamp,manufacturer,model_name,technology,charge_full,charge_full_design,charge_now,cycle_count,status,
        1540545130,Hewlett-Packard,Primary,Li-ion,3648000,3648000,3648000,0,Full,

Maybe it's lying to me but maybe not. I remember that HP described the battery more or less as "long lasting", not intending that it can power the laptop for all the day (it's about 3 hours, which is more than OK for me) but that it will keep going on for years without degradation.

</comment><comment><USER21> I live in Saigon and I was commuting about an hour each way with my Late 2015 MBP in my motorbike under the seat, where it gets hot (yes, stupid me). After a few months of this, I realized my laptop wouldn't shut properly. One of the speakers also failed. I took it into shop and found this [1]. The fans were also really dirty from working in a data center, so the machine was having a hard time cooling itself (good idea to clean those fans!). Luckily, being in Vietnam and close proximity to China, the repair was pretty cheap.

[1] [https://imgur.com/Dvo4Xw9](https://imgur.com/Dvo4Xw9)

</comment><comment><USER22> This data would be greatly enhanced if the number of charge cycles was also logged. From the graph it looks like that battery is deeply cycled frequently. That's hell on batteries.

At my org (a school) we used to disallow charging our students' laptops in class. We did that for about three years. During that time, it was not uncommon for a battery to fail in the first year, with most failing after two. Since we started allowing charging, most batteries stay above failure threshold the students' whole four years here. My hypothesis has been that students charging opportunistically avoid the deep discharge cycles that are very bad for batteries.

</comment><comment><USER23> "But why is this happening? Why are my laptop batteries always dying in a year or two, while the batteries of space probes and satellites keep working year after year. If we are to believe Battery University, the cause is me charging the battery whenever I have a chance, and the fix is to not charge the Lithium-ion batteries to 100% all the time, but to stay below 90% of full charge most of the time."

[https://batteryuniversity.com/index.php/learn/article/how_to...](https://batteryuniversity.com/index.php/learn/article/how_to_prolong_lithium_based_batteries)

</comment><comment><USER24> I think the MacBook charge controller (probably not all model years) will reduce the max charge to below 100% if it detects prolonged AC use to reduce wear. Of course, this means you won't actually get 100% when you may need it for the first deeper discharge.

One nice thing about the Dell XPS laptops (others too I assume) is that you can configure min/max charge in the BIOS.

In any case, just leaving my devices plugged in most of the time seems to have the battery last many years, with the exception of some Android phones that don't tolerate this at all. Improvements in the last 5-10 years have probably come from better charge controllers.

</comment><comment><USER25> Yet another insidious example of engineered obsolescence. Alternate battery chemistries (Lithium Iron Phosphate, Lithium Titanate)exist offering at least 4x-12x the durability and cycle life.

[https://en.m.wikipedia.org/wiki/Lithium%E2%80%93titanate_bat...](https://en.m.wikipedia.org/wiki/Lithium%E2%80%93titanate_battery)</comment>


WKWebView, an Electron alternative on macOS/iOS - <AUTHOR> https://holtwick.de/blog/2018-12-20-web-technologies <comment><USER2> This is literally what Slack moved from years ago, because it was very problematic, let me tell you why since I'm the one who did it.

* Adding new APIs was a huge pain in the ass, you had to write all of this ugly bridge code in Objective C, and the APIs ended up being super unnatural on the JS side. As a result, desktop integration wasn't done much since it felt like a "Black Magic" type thing. Writing new APIs in Electron is Just JavaScript, so you can make something much more natural.

* We could literally do fuck-all for people running old versions of macOS - you _can 't_ upgrade Safari on old machines, you just Get What You Get. For awhile, every YouTube video on older macOS versions had a pink shade to it. Users write in, "This is clearly wrong!" "Yep, but we can't fix it. Sorry."

* And big spoiler - WKWebView uses _basically_ the same amount of memory give-or-take a few MBs as Chromium. It's the _content_ that sets the memory usage bar, not the host.

<comment><USER3> Why doesn't Slack write an actual Mac app in Swift? For small companies with limited resources, I understand the attraction of "cross platform," but it would seem that performance and uasability would be vastly improved by writing actual native applications — especially for a billion dollar company that can afford to do it and especially since Slack is one of those apps that is constantly open and performance and efficiency have a real benefit.

<comment><USER4> They've cornered the market and don't have to care anymore.

A lot of Slack's audience is captive - employees, contributors to open source projects that chose Slack as their social outlet, etc.

<comment><USER5> The only way this will change is if Apple starts using more "stick" approaches. Marzipan and whatever other technologies they're working on are the "carrot".

</comment></comment></comment></comment><comment><USER6> If you throw out cross platform support it's hard to call it an alternative :)

<comment><USER7> It's pretty cross-platform, if you swap out "WKWebView" with "your platform's native web view".

<comment><USER8> Just use gtk WebKit or qt WebKit and you're good to go.

For the record, WebKit originated from KDE[1].

[1] [https://en.m.wikipedia.org/wiki/WebKit](https://en.m.wikipedia.org/wiki/WebKit)

<comment><USER9> Should be QtWebEngine now, as QtWebKit is deprecated.

<comment><USER10> QtWebEngine embeds Chromium as its web engine, which means it is going to have the same performance and disk size costs as Electron. The circle is now complete and you might as well just use Electron.

<comment><USER11> Agreed except each app won't need a copy of QtWebEngine on disk.

</comment></comment></comment></comment></comment></comment><comment><USER12> It would be nice to have an Electron 100% compatible framework (drop-in replacement) that instead of using Chrome, it would use Apple's webviews that are of course based on WebKit.

It would be faster and take much less RAM, specially when multiple Apps are open and they could use the shared library.

Also, now that Chromium is going to be part of Windows, the same would also be a good idea, I think.

<comment><USER13> So, every time Apple updates WebKit your app breaks. We've gone through this in the past. There are multiple reasons Electron is a win.

1\. It's cross platform

       Don't have to deal with the fact that Safari is missing these 12 APIs or has different edge cases

2\. It's stable after shipping

       Users get a new version only when you ship. If you use the native widget then users get a new (often broken) version on every update by a 3rd party (Apple/MS/Google). Example: chrome just deprecated autoplay. If that bubbled into apps your app just broke. Electron could do the same but if you're testing like a good dev that break wouldn't make it to users. You as a dev would find it locally, deal with it, and only after ship to users.

so, no personally I don't want a shared widget. that sounds like going back to DLL hell or worse, just broken stuff.

<comment><USER14> Doesn't stable after shipping also mean that if a critical vulnerability is found in the version of electron/chromium that you've bundled, the user is vulnerable until you are able to issue a fix? What if the app itself is no longer updated?

<comment><USER13> How is that different than any native app? All native apps have that issue.

<comment><USER15> Native apps can benefit from using shared libraries, which can be updated in such case. Using WKWebView ensures that vulnerabilities are patched as part of OS updates.

On OSes with sane package managers (e.g. Linux distributions) native apps can share all dependencies, so there is no need to recompile/redistribute each application using affected library.

Sadly, there is no such thing on MacOS (excluding brew/port) and Windows (or even iOS/Android), and even native Linux applications are moving towards bundling all dependencies in a single package.

</comment></comment></comment></comment></comment><comment><USER16> This reads like someone hired a consulting firm to send out surveys asking why people don't like Electron apps, without really understanding the problem.

None of the four bullet points actually address real issues. The security problem isn't that Google is bad at security (they're among the best really). The problem is that Javascript code is generally written with the expectation that it will run in a web browser's highly locked down security context. Performance is really the same issue: web apps are authored wastefully. For use cases where you visit a web page for a few minutes then leave that's fine, but when you then let that code run for hours with no sandbox you will inevitably hit perf issues.

Write native apps. If you can't afford that, just make a web page.

<comment><USER17> Electron also has a lot of hardening features from chromium disabled as is strongly discouraged by Google as unsafe to use for apps.

<comment><USER18> This seems to be changing as of recently this year. There have been many security-related changes including making options such as Node integration disabled by default [1]. Support for renderer process sandbox is also available [2].

[1] [https://github.com/electron/electron/pull/14284](https://github.com/electron/electron/pull/14284)

[2] [https://electronjs.org/docs/api/sandbox- option](https://electronjs.org/docs/api/sandbox-option)

</comment></comment></comment><comment><USER19> MacGap framework [1] builds on the same idea. In fact, it predates Electron and was being used by Slack. The size of the compiled binary would be just ~350KB.

[1]: [https://github.com/MacGapProject/MacGap2](https://github.com/MacGapProject/MacGap2)

<comment><USER20> Wow, I used this in 2012. I think it was originally written by Alex MacCaw of Clearbit.

</comment></comment><comment><USER21> I still live in the world of heavy desktop native apps (WinForms & WPF) and one thing I've never been able to understand about all of these Electron discussions is what benefit does Electron bring in the first place? Why not simply run the application and connect to it using the local browser instance? For convenience a link can be placed on the users desktop.

<comment><USER22> It sells the dream of using web developer skills on the desktop, for those who want to develop native apps but don't want to learn new tools/languages.

Square peg, round hole. Electron just gives you a hammer to make it fit anyway :)

<comment><USER23> It also sells the dream of writing an app that works on multiple platforms. The web is good at this but depending on what your app does you might need more. For instance, in Electron you have access to Node. This lets you do things that you wouldn't be able to do in the browser. It would let you do lots of things but for example: access local file system, use SQLite or some other storage without requiring a network connection, add an icon to the menu bar or taskbar on Mac/Windows, you could even control a users mouse for something like screen sharing.

<comment><USER22> I write native applications, cross platform (I generally make releases for Windows, Mac, and Linux), and cross-compiled using FPC + Lazarus.

No trickery, no hidden browser windows, just normal native executables.

Java also solves the cross-platform issue, though it's GUIs tend to not look native (As opposed to Lazarus above, which is native).

If you're impressed by a webserver being able to interact with the OS for things like accessing files or databases, your mind will be absolutely BLOWN when you learn real native development.

<comment><USER23> You're making an assumption I haven't already learned real native development but that's besides the point.

Java does solve part of this but some people would rather use JavaScript than Java. Even if they know how to use both believe it or not.

However, if one of your platforms is the web browser, nothing is going to work better than a web view if you want a cross platform solution. Slack for example works almost exactly the same in my web browser as it does in electron. If you want a solution that works on Linux, MacOS, and Windows AS WELL as the web browser then the web view approach is pretty obvious.

Lastly the JavaScript web development experience is great with hot module relacement and Chrome's developer tools. Not to mention the JavaScript open source community is amazingly strong and there is a lot of innovation going on. To simply dismiss all of this because of personal reasons is fine by me but I don't agree with your view.

<comment><USER24> "It works the same on the desktop as it does in my web browser" is an indictment, not a feature. People use cross-platform toolkits because they don't want to do the work to fit in with the platform their user chose, not because they confer any advantages to the user.

<comment><USER23> That is certainly one way to look at it. I'll propose another way to see it: There are always trade offs. For example, you could hire enough people to simultaneously work on a Mac OS version, a Windows version, an iOS version, an Android version and a web version of your product. Of course this is going to cost a lot of money and this cost will be passed on to the users. If the users prefer the subtle differences between the UI in platforms so much that they would prefer to pay more for a product than that would be an advantage. Otherwise that is a disadvantage. Potentially a really big disadvantage. There is also a case to be made that some people would definitely want the product to work the same in the web browser as it does on their desktop. Slack is a good example of this. I don't want to learn a new user experience for the moments when I'm on another machine without Slack installed and I just want to respond to a comment quickly, I'm very happy the web experience and the desktop experience are similar.

Making absolute statements about why people make certain choices or believing them can definitely lead to false conclusions. People don't only use cross platform toolkits because they do not want to do work. Sometimes it is the best solution given the features and constraints. I like to think of it as being pragmatic.

</comment></comment></comment></comment></comment></comment></comment><comment><USER25> The web and its technologies are far from stable, cheap and simple to learn. And browser-based UIs are pretty much where native UIs were 30 years ago, just a bit slower.

Cross-platform: yes, if you ignore the fact that there are only 2 browsers left, both being buggy and incomplete (as they've been for many years) and with no other implementation in sight, or even remotely feasibly for small to medium-sized companies or teams. Also they're so bloated and isolated from the native environment that you might just as well install a Linux virtual machine and call it a cross-platform UI.

No, thanks. I'll wait for a better cross-plattform UI solution.

<comment><USER26> > pretty much where native UIs were 30 years ago,

In reverse, I would argue, Hundreds of "Native UIs", most of them obsolete or dead, have shown to be incapable to express cross-platform, flexible layout capabilities of 1990s HTML/CSS combo.

The most recent, yearly updated mobile OSes appear to be cooler, however we'll see in 10 years how they will end up.

<comment><USER25> > In reverse, I would argue, Hundreds of "Native UIs", most of them obsolete > or dead, have shown to be incapable to express cross-platform, flexible > layout capabilities of 1990s HTML/CSS combo.

But most haven't. If you want the capabilities of the HTML versions unable to even center vertically or requiring invisible images to format tables, there are plenty of UI to choose from. Qt, Wx are extremely capable nowadays.

</comment></comment></comment><comment><USER27> I don't understand why the entire browser engine needs to be bundled with each app.

Why not have libchrome or a libelectron that moves more slowly than chrome six week release cycle (maybe do 6 months) then have apps build to it and share the library.

<comment><USER28> Developers target a runtime with very specific APIs. If the runtime changes developers wouldn't even bother to write the apps.

If Electron apps would specify requirements instead of bundling the whole runtime, you will have to wait for the runtime to be downloaded the first time the app runs. You will still end up with multiple versions of the same runtime running on your system.

<comment><USER27> Is it possible to stabilize the runtime or is it moving too quickly?

<comment><USER29> Not for all applications, but for enough applications to make it well worth it.

</comment></comment></comment></comment><comment><USER30> The most obvious Electron alternative on _any_ platform is of course doing things the way we sort of used to: Get your toolkits and compilers out, your hands dirty, and your integrity clean and code some honest to God desktop applications.

If you absolutely need to do web primitives inside your app, well then, html engines used to come in a few megabytes and no external deps. If your webcode needs the entire Chromium monstrosity bundled in order to run, someone has been doing something entirely wrong.

<comment><USER31> The most obvious counter-argument: one shared codebase vs. your five.

Native is awesome when you have the money.

<comment><USER22> Meh, I write cross platform applications, single code base, and compile to native executables on Windows, Linux, and Mac with no problem and no extra Chromium bloat.

FreePascal + Lazarus.

<comment><USER32> I've done delphi in the past but I haven't heard about it for a while. How big is the community nowadays? What about libs? Package manager? Dependency-hell? Unit-testing frameworks and other toolings? How easy is it to stop the whole application and inspect everything, evaluate some code in parent stack and see if the issue was resolved so that you know exactly what to do?

It's not only about GUI designer and fast cross-platform compiler.

<comment><USER22> Online package manager can search, download, and install packages.

I have libs/packages for everything I need, dunno about your needs.

Not sure about the community size but it's plenty big and plenty helpful, lots of cool new stuff going on.

Plenty of debuggers available and you can pause things and inspect stuff.

Lazarus has seen loads of updates the last few years, it's worth taking the time to set it up to fit your needs and learn the shortcuts.

</comment></comment></comment></comment></comment><comment><USER22> Let's move away from hiding browsers in windows and pretending they're not browsers hiding in a window.

FPC + Lazarus, native executables, cross platform.

<comment><USER33> You've mentioned this several times now as though it's some magic sauce that everybody is missing.

But it's not like FPC/Lazarus is the only portable GUI solution — Qt, Fox, Swing, SWT, Gtk etc. also exist, and don't require a fringe language (and I say that as someone who did Turbo/Borland Pascal and Delphi development for more than a decade). What Lazarus offers is a Delphi-type form builder tool, but that seems a lot less interesting in this day and age of heavily customized UIs that aren't static grids of square components — in particular, we increasingly rely on responsive layouts and smooth animations between them.

Moreover, I've yet to see a FPC app (or any app for that matter that isn't Electron or web) that doesn't look like an old fashioned Windows-style GUI app. Do you have any examples?

<comment><USER22> It's not magic sauce, it's a counter-point to the "Electron gives you cross platform deployments" argument.

Yes, there are many GUI toolkits, the LCL creates native applications while some others do not, but it's certainly not the only one.

It's the one I prefer so I use it as an example over QT, Swing, JavaFX, etc.

Lazarus form builder let's you create forms very quickly and easy, and OS themed design.

If you want other types of GUI designs you can do that too, though personally I prefer standard OS design.

As far as static grids and square components, I think you're looking at old stuff..

You can make things as squiggly as you like, and of course you can always use images and colors to design your GUI and let your imagination run wild, and it'll look entirely non-native.

Responsive design isn't that challenging either, use anchors and smart design.

I don't have any examples of desktop applications I've made, that look like web-apps, no, but I might make some after you giving me this idea, and I'll be doing it with FPC/Lazarus.

<comment><USER33> I'm still not convinced that it's relevant to the discussion — it's an old- school GUI builder, Electron isn't, and it's a bit of an apples-to-oranges comparison.

People gravitate to Electron not just because you can't build cross-platform apps in it, but _because the underlying UI tech is just the web_. You can even do as Slack did, which is to offer the exact same app in the browser. You can't do that with FPC/Lazarus. The latter is geared towards fairly static layouts, not the kinds of snappy, fluid, single-window apps that Electron is used to build. It's just a very different world.

Nobody is doubting that you can build decent Windows-style apps with FPC/Lazarus, just as they're not doubting that you can do it with Qt.

<comment><USER22> It's arguably the most advanced gui builder available.

As for snappy, fluid, single-window apps that is 100% doable and up to the gui developer.

It's not hard to use groups and switch between views, and make things dynamically resize or move around.

</comment></comment></comment></comment></comment><comment><USER34> Recently there has also been some interest in making chrome usable as a runtime to load web content as/in native apps, especially since with native webview the experience would vary across different platforms (windows 10 below will try to load it on ie!), i was working on [https://github.com/SiDevesh/Quark-Go](https://github.com/SiDevesh/Quark-Go) using the cool [https://github.com/zserge/webview](https://github.com/zserge/webview) library, recently started redoing it with [https://github.com/GoogleChromeLabs/carlo](https://github.com/GoogleChromeLabs/carlo)

</comment><comment><USER12> The author is wrong in one point, Electron is not based on Chrome, it's based on Chromium, and you don't need to trust Google because it's 100% open source.

<comment><USER35> By default, Chromium still integrates heavily with Google services. See project ungoogled-chromium for details: [https://github.com/Eloston/ungoogled- chromium](https://github.com/Eloston/ungoogled-chromium)

<comment><USER36> Since when does electron make you log in with Google?

<comment><USER37> Integration with Google services does not require logging in to Google services.

For a benign example: using Google search

For a less benign example: your browser/device/network being tracked for ads when using Google search

<comment><USER36> Electron is not a search engine or a browser, and it does not serve ads.

<comment><USER37> Google Play Services (on Android) is not a search engine or a browser, either.

Google Home does not serve ads, either.

My original comment's grand-parent did not claim if Electron was a browser or a search-engine, or if it showed ads, just that it is not necessarily independent of Google services just because it's built from Chromium.

</comment></comment></comment></comment></comment></comment><comment><USER38> The problem with electron isn't electron -- it's the standards that it's built on. Replacing one flavor of it with another doesn't move the needle significantly.

</comment><comment><USER39> I posted this earlier in an Electron discussion, but there are a couple of libraries that take this approach cross-platform, like zserge/webview [1] and Tether [2].

[1] [https://github.com/zserge/webview](https://github.com/zserge/webview)

[2] [https://github.com/quadrupleslap/tether](https://github.com/quadrupleslap/tether)

</comment><comment><USER40> Rails Turbolinks utilizes this technique for iOS: [https://github.com/turbolinks/turbolinks- ios](https://github.com/turbolinks/turbolinks-ios)

Video explanation/demonstration: [https://youtu.be/SWEts0rlezA](https://youtu.be/SWEts0rlezA)

</comment><comment><USER41> Cross-platform is the key problem.

If I want to write a Mac-only app, I can do that in Objective-C/Cocoa, and be quite happy.

For Linux, native means fighting with primitive C and X11 or Gtk, etc., which I can do but I loathe it.

For Windows, I have no idea, C# maybe? I'd rather eat broken glass than install Windows and find[ed.] out.

So if I'm doing cross-platform, my current working choices are Electron, Java, FreePascal/Lazarus, or Scheme.

Electron's easy to build all three platforms on, performance is OK despite the bloated example of Slack.

Java would need to bundle the JRE everywhere, and I've been largely Java-clean for 10 years.

Lazarus is semi-broken on Mac currently, only 32-bit like stone age tools, Cocoa port is unfinished. Maybe they'll get their shit together someday, I like it when it works.

Scheme native binaries are hard and experimental, but getting better.

Using a WKWebView on Mac, then writing a completely different wrapper on Linux & Windows, is unacceptable for my uses.

So my actual shipping code is Electron.

</comment><comment> see-ya-99 Electron and other wrappers are just shit in my opinion as these consumes a lot of precious resources.

Maybe devs instead of being lazy suckers could start to worry about this aspect.

<comment><USER42> Give it a few years. We're at the limits of what's photolitographically possible with silicon. As soon as Moore's law halts all this wasteful crap will go down the shitter.

</comment></comment><comment><USER43> This is perfect for writing compact and portable web apps. I built a basic chrome that runs an index.html page and everything linkable after that and all I have to do is inspect myweb.app file and change whatever html, css or js I want. Simpler impossible. And with a little help from Swift I can have all the power of macOS in my hands.

It is neither a hammer nor a nail, it just works for some specific purposes.

</comment><comment><USER44> This is how Apache Cordova (previously PhoneGap) works.

[[https://cordova.apache.org/](https://cordova.apache.org/)]

</comment><comment><USER29> WkWebView is a huge improvement over UIWebView on iOS or WebView on macOS.

However on macOS it is missing one important feature (to me at least) that used to work with WebView:

You can't capture the image of the web browser window any more.

You used to be able to go something like:

        NSBitmapImageRep *bitmapdata = [view bitmapImageRepForCachingDisplayInRect: bounds];
        [webView cacheDisplayInRect: bounds toBitmapImageRep: bitmapdata];

Or:

        [NSView cacheDisplayInRect:(NSRect)rect toBitmapImageRep:(NSBitmapImageRep *)bitmapImageRep]

But that's a synchronous API, and since WkWebView runs in another process, it requires a remote procedure call, so Apple simply returns a blank image from that call now.

[https://stackoverflow.com/questions/31969950/wkwebview- cache...](https://stackoverflow.com/questions/31969950/wkwebview- cachedisplayinrect-screenshot-in-os-x)

I think the iOS way of capturing a screen snapshot from WkWebView still works, though, but I can't remember off the top of my head...

However, Apple added a new method to Safari, but last time I checked it was only in the beta Safari and not supported in the version installed on the operating system. (When you make a WkWebView it uses some specific framework that's not necessarily the latest beta version of Safari you've installed.)

//iOS func takeSnapshot(with snapshotConfiguration: WKSnapshotConfiguration?, completionHandler: @escaping (UIImage?, Error?) -> Void)

//macOS func takeSnapshot(with snapshotConfiguration: WKSnapshotConfiguration?, completionHandler: @escaping (NSImage?, Error?) -> Void)

But the problem with this method is that it takes a totally different rendering path ("this is a software painted snapshot"), so some stuff may look different, and WebGL stuff doesn't appear, and it's a whole lot slower than cacheDisplayInRect used to be).

[https://stackoverflow.com/questions/46842384/wkwebkit- takesn...](https://stackoverflow.com/questions/46842384/wkwebkit- takesnapshotwith-snapshotconfiguration-not-working-on-ios-device)

This bug describes the problem and the issues and the less-than-ideal solution:

[https://bugs.webkit.org/show_bug.cgi?id=161450](https://bugs.webkit.org/show_bug.cgi?id=161450)

Summary: [Cocoa] No reliable way to get a snapshot of WKWebView

<comment><USER45> I hear a lot that WKWebView is an improvement, but all I see are some pretty significant limitations compared to WebView:

\- no screenshots

\- no printing

\- no user stylesheets

\- no cmd-F find

\- no delegate method for hover-over-link

\- no access to container NSScrollView (on macOS)

\- harder to customize context menu (AFAICT)

\- ignores URLProtocols (10.13 added a new way to implement custom protocols for WKWebViews with a completely different interface than NSURLProtocol/WebView)

I'm dreading the day when Apple is going to require me to 'upgrade' my WebView to WKWebView.

All I want to do is supply a byte stream containing HTML, and have it displayed in an NSView, with standard features. This doesn't seem like an obscure case, or a difficult problem. I don't understand why none of Apple's web views ever had simply a load(stream:NSInputStream) method. This was hard with WebView, and WKWebView made it a lot harder.

<comment><USER29> Yes, it's a mixed bag with some things better and others worse. But having a great JavaScript engine with the JIT enabled is pretty important for many applications.

But breaking up the browser into different processes and communicating via messages and sharing textures in GPU memory between processes (IOSurface, GL_TEXTURE_EXTERNAL_OES, etc) is the inextricable direction of progress, what all the browsers are doing now, and why for example Firefox had to make so many old single-process XP-COM xulrunner plug-ins obsolete.

IOSurface:

[https://developer.apple.com/documentation/iosurface?language...](https://developer.apple.com/documentation/iosurface?language=objc)

[https://shapeof.com/archives/2017/12/moving_to_metal_episode...](https://shapeof.com/archives/2017/12/moving_to_metal_episode_iii.html)

GL_TEXTURE_EXTERNAL_OES:

[https://developer.android.com/reference/android/graphics/Sur...](https://developer.android.com/reference/android/graphics/SurfaceTexture)

[http://www.felixjones.co.uk/neo%20website/Android_View/](http://www.felixjones.co.uk/neo%20website/Android_View/)

<comment><USER46> Chrome and Firefox with WebRender are going the opposite direction and just putting all their rendering in the chrome process/"GPU process" to begin with.

<comment><USER29> Yes I know, that's exactly what I meant by "breaking up the browser into different processes". They used to all be in the same process. Now they're in different processes, and communicate via messages and shared GPU memory using platform specific APIs like IOSurface. So it's no longer possible to write an XP/COM plugin for the browser in C++, and call it from the renderer, because it's running in a different process, so you have to send messages and use shared memory instead. But then if the renderer crashes, the entire browser doesn't crash.

</comment></comment></comment></comment></comment><comment><USER47> > It is cheap

And so the results look cheap.

</comment><comment><USER48> Emm... nativescript?

<comment><USER29> NativeScript is cool -- I really like it.

But as far as I understand it, there's a bit of a fatal problem going forward on iOS, last time I looked at it a year or so ago (I'd be thrilled if they've come up with a way to address this problem):

The iOS NativeScript bridge uses the old deprecated UIWebView and JavaScriptCore's Objective C integration stuff that lets you directly call back and forth between Objective C and JavaScript.

However, that Objective C bridging stuff is not supported on WkWebView, since it runs in a separate process, and has a different way of sending messages to the web browser, but not calling native code directly or passing pointers to objects or buffers in memory.

Why would you want to do that? To get direct access to an array of binary floating point numbers, or the pixels of a canvas or WebGL texture, instead of converting to and from JSON, or serializing images as data urls with base 64 encoded png files, for example. (Yech!)

You can send messages back and forth to WkWebKit, but that's vastly less performant than the direct calling UIWebKit JavaScriptCore bridging stuff, which operates in the same process and memory space.

And the NativeScript iOS integration layer is totally dependent (built on top of) on the way the JavaScriptCore bridging stuff works, and would have to be completely rewritten from scratch (and be much less efficient and require a lot more plumbing on both sides), in order to support that kind of out-of- process messaging to WkWebKit.

The great thing about NativeScript is that gives you has such an efficient high bandwidth interface to native code from JavaScript. But it just necessarily uses an old crappy JavaScript engine with no JIT.

One of the best thing about using WkWebKit is that the Just In Time compiler is enabled, so it's blazingly faster than running JavaScriptCore in the same process (which has it disabled, since non-Apple apps aren't allowed to write to code memory).

Of course it depends on how much of your application is written in JavaScript and would benefit from the JIT, and how much it depends on calling and sending data back and forth between native code and JavaScript. But the NativeScript way of doing things makes many assumptions that would make it very slow with RPC messaging instead of direct calling.

PhoneGap/Cordova is fine using WkWebKit because it uses a JSON messaging interface in the first place, not the more efficient higher bandwidth Objective C bridging stuff. It's JavaScript/Objective C bridge is much simpler than NativeScript, and people don't use it the same way that NativeScript is designed to be used.

NativeScript, as cool and amazing as it is, is deeply tied to old technology on iOS, JavaScriptCore and UIWebKit.</comment></comment>


There is an Open Source Rival to Facebook: WordPress - <AUTHOR> http://steveburge.com/blog/wordpress/wp-facebook/ <comment><USER2> I think people on HN tend to forget that most people dont care about the technical requirements etc. The reason people use facebook because its usage is clear and defined for what its build.

You go on Facebook to check in with your friends, see photos, chat/message. You just dont do it with a blog.

It's like saying you could use paper towels as toilet paper. There is probably some overlap in functionality, but people clearly associate types of products with their specific use case

<comment><USER3> The analogy here would be more like using books as toilet paper....

<comment><USER2> Indeed, I should step up my English skills

</comment></comment></comment><comment><USER4> I don't see how this is different from saying "The World Wide Web is the open source rival to Facebook".

It's true. There isn't anything about Facebook you can't do with your own website. Facebook just centralizes it and makes it easier on the digitally challenged. It's the Geocities of the 21st century. And it too shall eventually crumble, while the Web continues on.

Make it easy to host, set up, administer and link websites and you will have defeated Facebook. Unfortunately, that's easier said than done. People have been trying for 20 years.

<comment><USER5> I think a well designed Google+ API and infrastructure could be integrated into WordPress effectively to form the missing pieces of a "social" backbone. That's how Google+ can succeed in my mind--as a view-agnostic infrastructure that sites can build off of to add the social features. It seems that people think that G+ must succeed as a specific destination, but I think it can spread and succeed in more "hidden" background role.

<comment><USER6> I feel like drcube's comment could be repeated to you here. Anyone's components could be plugged together to create an identity service and a synchronized or centralized stream of data ("microblog posts" ala Twitter, a "news feed" ala Facebook, a photostream ala "Instagram") etc. The hard part is composing it into a platform or something that appears as a centralized platform in order to get people to use it.

<comment><AUTHOR> Yes, the secret sauce here is potentially Automattic. With WordPress.com, Gravatar and a substantial hold on WordPress.org, they have a rare opportunity to create a centralized platform.

<comment><USER6> So the question I've asked elsewhere applies... what advantage is it that WordPress is open source now? If they're going to turn it into a social network, they're either going to have closed components (specific to Wordpress.com) or they're going to have to re-invision (and reimplement larges chunks of) it as a distributed social network, something that you seem to be happy to dismiss Diaspora of trying to do. Otherwise, it's just as "closed" as Facebook if I _have_ to use a Wordpress.com site.

I feel like there is a massive misunderstanding of what Jetpack does and provides in the way of a social network. All indications I've seen is that Jetpack just shares to other social networks. It does... effectively nothing... to provide an alternative free of other social networks.

I mean, you even call out Gravatar as being "owned" by Automattic. I don't mind Gravatar but it's a bit stale and certainly not in the vain of a distributed or "open" social network.

Maybe I'm misunderstanding but I don't see how Wordpress is anything like a social network other than you citing the fact that it can tie into other ident providers and share to other social networks. That describes... a metric ton of sites out there.

<comment><AUTHOR> Sure, it may be that Automattic may need to release more closed products if they want to implement this vision

It may not even be the vision they have for Automattic ... but I do think it's an opportunity they have.

For Gravatar, no it's not a social network at all, but it's a potential part of a bigger, wider identity platform.

<comment><USER6> >it may be that Automattic may need to become a more closed if they want to implement this vision

If we're just discussing Automattic becoming a closed Facebook competitor, sure it's possible. I think they have the position to do so, but I'm certainly not interested in another closed platform, even if bits of the core software are free.

Gravatar is a wider identity platform, but it too just piggy backs on email. It's an avatar platform that piggy-backs on the email identity platform. And sadly, the avatar platform isn't distributed either.

In my opinion, BrowserID has a much better chance of being the technical and featureful identity provider. Anyone can be a BrowserID provider and provide any level of security from literally none to quadruple factor auth with PKI if they wanted. I would love to see proposals on how to layer functionality like Gravatar on top.

 _That's_ a social network alternative that I could get excited about!

</comment></comment></comment></comment></comment></comment></comment><comment><USER7> The author seems to conflate WordPress _the software_ and WordPress.com _the service_.

> You control the source code. You can easily export your site from > WordPress.com and take your site with you.

Only if you download WordPress from wordpress.org and install it on your own server (or shared hosting account). The dot-com version contains a lot of proprietary code.

> WordPress.com has already become a login option on many different websites.

Only if you opt to host your blog with them. WordPress.com is a great service, but hosting your blog there is mutually incompatible with having complete control over the source code. Besides, half the WordPress sites out there are self-hosted, and WordPress.com logins don't work there.

Some of the features the article mentions, like JetPack, may be available for both WordPress.com and self-hosted WordPress blogs. But that's just comments. There is no meaningful aggregation between WordPress.com and self-hosted WordPress blogs when it comes to posts and pictures. Until there's an easy way to follow a lot of WordPress blogs no matter where they're hosted (hello, RSS), it will be difficult to make the argument that _WordPress the software_ makes a promising social networking platform.

What we really need if we want a _distributed_ and _open-source_ social networking platform is improved interaction between independent sites. Not with newfangled stacks like Diaspora, but something that can be slapped onto any existing blog, microblog, or photo sharing service as a plugin (again, think RSS but much more powerful). Why limit your network to WordPress.com users, or even all WordPress users? Give me a common API that lets me follow folks on WordPress.com, DeviantArt, and Pinterest at the same time, a gem that I can add to my Rails-based blog to support this API, and a nice open-source client that ordinary people can use to access all that data. If a few companies like Mozilla and WordPress.com started collaborating on this, it would be a thousand times more viable than Diaspora can ever be.

<comment><USER8> I agree with you, but I think the author is trying to get at what WordPress _can_ do, not what is currently in place.

<comment><AUTHOR> Yes, very much so. This post was about the cards that Automattic hold in their hands and really is just one idea about how they could play them.

</comment></comment></comment><comment><USER9> I see we are continuing the tradition of shoe-horning WordPress into roles it was not designed for.

<comment><USER10> As I understand it, Emacs was originally a text editor.

</comment></comment><comment><USER11> The main open source alternative to Facebook is Friendica. It has more features than Diaspora, encrypted communications, emphasis upon decentralization and you can install it easily on a LAMP stack. You don't have to settle for being data mined and sold by Mr Zuckerberg, or owned by the Communications Data Act.

</comment><comment><USER12> Sites aren't people. It's linking wp sites. Don't even see how this stands even in general concept of 'facebook rival'.

Technically, it sounds plausible (?), but that's irrelevant.

<comment><AUTHOR> Yes, it's plausible and that's the main thrust of the argument.

I'm not even sure Matt M. has a clear idea of how the direction this might play out but it might be like this:

\- build a huge set of site running the same codebase (done) \- start to connect them on the admin level (doing) \- start to connect the on the user- facing level (starting)

</comment></comment><comment><USER13> The issue isn't publishing, or even selective publishing, it's _smart aggregation_.

You'd still need a solution like a feed reader or a site like FriendFeed. And even then, you don't have the interactivity of FB with the ability to "like" content, comment, and tag. It's the content that brings people to FB, the opportunity to see who's up to what, look at funny photos and chat and gossip with friends.

</comment><comment><USER14> This is a very interesting analysis. It's one that I would've never thought of, but seems accurate. The fact that wordpress powers a great majority of sites would be a huge factor in their success at playing the "social" game. Funny, though, that most of those sites also incorporate FB "like" buttons. Good read.

</comment><comment><USER15> WordPress: PHP-Nuke for the new generation.

</comment><comment><USER16> Give me a break. My family isn't using Wordpress and I don't see them use Wordpress in near or far future.

<comment><AUTHOR> True, at the moment it's only site owners and WordPress.com bloggers who are really tapped into this network.

We're talking about potential here.

As more end-users features like comments get added to JetPack, the chance is there to entice more users like your family.

</comment></comment><comment><USER17> Sorry but this just seems to miss the point of how Facevook bested competitors that, in theory, covered the same ground as FB did (Friendster, MySpace, xanga, etc). Execution is as important as e idea...and FB, by focusing on a narrow band of features and customization, created a service that was easy to use and addictive. Nothing about Wordpress or the plugins required to get it to FB functionality will match this.

This is like saying that WP is the open-source alternative to Titter, except that you can write more than 140 characters and even add photos/tables/anything...Twitter is more than just a text and newsfeed platform

</comment><comment><USER18> When you look at open and portable software for personal sites, as people in the Indie Web community do, WordPress is an obvious frontrunner. Facebook and WordPress started in very different places, but because they've expanded to provide a lot of tools for establishing an online presence, there is certainly some overlap. For instance, some businesses use their Facebook page as a blog.

By the way if you like running your own site and can make it to Portland at the end of the month, consider going to <http://indiewebcamp.com/>

</comment><comment><USER19> The pendulum does always swing away from a walled garden. The author makes a compelling case for Wordpress as a distributed and open potential social platform.

Love to hear what Matt thinks about it.

<comment><USER20> »" _The pendulum does always swing away from a walled garden_ "

I sympathise with the sentiment expressed but must point out that there is no market force that prefers un-established open products to established walled gardens save for a fraction of hackers' tastes and preferences. Most people don't care, for rationally self-interested reasons, whether the product they use is open or closed as much as whether it works or not.

<comment><USER21> >>I sympathise with the sentiment expressed but must point out that there is no market force that prefers un-established open products to established walled gardens save for a fraction of hackers' tastes and preferences.

Oh, yes there is, it's called change.

<comment><USER20> The point isn't that established players are immortal. It is that the role of open v closed in that usurpation process is negligible.

Closed systems overturn open systems just as much as the other way around (or closed v closed or open v open). Very few people outside hacker culture care whether what they use is open or closed.

</comment></comment></comment></comment><comment><USER22> <$0.02> Android not WordPress</0.02> Its not about Open 'source' but simply 'open'. Weak proof of this is the Facebook Phone rumors a while ago. What if FB could at this stage own Android? FB wants/needs hardware presence for longer term. Too bad Google is too focussed on "Social" as defined by FB.

</comment><comment><USER23> jetpack and buddypress together would seem to give you a distributed-facebook experience.

<comment><USER24> Wordpress should take on Buyypress' profile information management system [xprofile], that would make Buddypress much more attractive imo. The fact that a user sees completely different information in the wp-admin dashboard from the data they entered into the Buddypress front end is very confusing and messy from a UX stand point.

</comment></comment><comment><USER25> Nope.</comment>


Show HN: Chartss.css – accessible HTML/CSS charts with markdown support - <AUTHOR> https://rbitr.github.io/ChartS.css/ <comment><USER2> Interesting the author mentions he is inspired by MVP.css[0]. I am in the process of changing my home page yet again to remove the current CSS framework I used. No more classes. After a few months not touching my site I find don't understand my own web site. Interestingly I still remember HTML elements I learnt in late 90s. I am sticking to styling HTML and will use one of the minimalist CSS frameworks that have been popping up on HN[1][2] of late. I see this can be used with pandoc, I just installed pandoc yesterday to see if I should use pandoc as my static site generator. Look forward to trying this out.

[0][https://andybrewer.github.io/mvp/](https://andybrewer.github.io/mvp/) [1][https://github.com/dohliam/dropin-minimal- css](https://github.com/dohliam/dropin-minimal-css) [2][https://news.ycombinator.com/item?id=23220081](https://news.ycombinator.com/item?id=23220081)

<comment><USER3> I find all of these css framworks baffling. They're like "this simplifies everything all you need is

Hello, World!

        </>

"

and…what??

I MVP looks cool, will check that out

<comment><USER4> Heh reminds me of assembly.

</comment></comment></comment><comment><USER5> This looks great!!

I love the simplicity of the bar charts.

I'm just wondering how the line chart is actually more accessible than an inline SVG of the same chart. You go through a lot of trouble creating lots of
 tags, but you could also just emit an SVG with ARIA annotations (or alternatively some hidden HTML that is read by accessibility tools).

<comment><USER6> I've never tried to read a SVG with a screen reader, do they attempt to read SVG's?

I would assume it would just treat it as an image.

<comment><USER7> Screen readers read SVG's.

[https://developer.paciellogroup.com/blog/2013/12/using- aria-...](https://developer.paciellogroup.com/blog/2013/12/using-aria-enhance- svg-accessibility/)

</comment></comment></comment><comment><USER8> Functionality looks decent, but the 3 different names for this project are a bit too "cute" for my taste.

Url is [https://rbitr.github.io/ChartS.css/](https://rbitr.github.io/ChartS.css/)

It refers to itself as C:greenheart:SS.css (what?)

Aka ChartSS.css - clever, but neither descriptive or memorable.

Edit: The fact that I can't even rag on the name in the comments due to the emoji makes me feel more justified in my original assessment. :P

<comment><USER9> Yeah, calling something accessible and then sticking an emoji in the name which screws over people with screenreaders is classic.

</comment></comment><comment><AUTHOR> Thanks everybody for all the feedback. Lots of things for me to clean up I see - it's great to have people looking at it

</comment><comment><USER10> The markdown generation in ingenious. This will integrate well with static site generators, and the charts are extremely lightweight.

I posted a Show HN a while back for charting project that is also minimal (zero) dependency, in a sense: [https://github.com/typpo/quickchart](https://github.com/typpo/quickchart)

It's a web service that takes a Chart.js config and renders the chart as an image. Downsides compared to this: not accessible, not as lightweight. Upsides: works in email clients (most of which disable flexbox) and other embedding situations, more customization via Chart.js

<comment><USER11> I might need this at [https://seekwell.io/](https://seekwell.io/) soon. I was going to render things with a headless browser, but this would be much simpler.

Curious, how do you rate limit? IP address?

<comment><USER10> Yes, the free API is rate limited by IP. Feel free to reach out if I can help (email in profile)

</comment></comment></comment><comment><USER12> I like that and might use it for my markdown note-taking app.

However, it seems that there's an alignment issue between the axis' values and their points (or bars) on the graphs. The stacked bars total value is 95, yet it seems to go a bit over 100, and the problem is even more apparent on Line and Scatter plots. Nothing too major to fix I guess.

The non rounding on axis values (0, 20, 39.9, ... 99.8) is also a bit weird. Sorry I don't want to sound negative, I'm really interested and will keep an eye on it!

<comment><AUTHOR> Thanks for the feedback - I agree that I need to do some work on how the axes scale and where the ticks go, and I see the bug you are talking about with the axis being greater than the sum. I think it is due to the placement of the tick. The very top of the axis is 99.8 but the label gets placed a bit lower so it looks like that. Will sort that out.

<comment><USER13> You don't have to override the template in the lua code to include the mvp.css file. use --css argument to set the location of the css file. it can even take multiple arguments (one for mvp.css and one for chartss.css).

In the current state, your "function Doc(" block upsets existing pandoc workflows.

Edit: didn't want to sound harsh with only the criticism :) Thank you for showing how to use lua-filters to do really cool stuff. I've playing with lua- filters, but your code is a clear example of how to extend markdown with a mini-DSL.

Edit 2: Sent you a PR on github with what I was suggesting here.

</comment></comment></comment><comment><USER14> Interesting! The project url is a little confusing, I think you should rename to rbitr/ChartSS.css (double S). To match the project name.

</comment><comment><USER15> > Stacked Bar (a pie chart for grownups)

That made me laugh, but the scale on the y-axis is odd. The inputs are all integers but the generated tick labels are floats (e.g., ).

</comment><comment><USER16> [https://css-tricks.com/making-charts-with-css/](https://css- tricks.com/making-charts-with-css/)

</comment><comment><USER17> Please don't use ultra light font weights, they are not accessible

<comment><USER18> Couldn't people just set their user agents to ignore or replace lightweight fonts with standard ones?

<comment><USER19> I guess you are talking about user stylesheets and not user agents. Yes, they could but there's a lot of lightweight fonts you'd have to hardcode.

Also that's not possible on (most) mobile browsers and it shouldn't be something people have to do just to be able to read something in the first place.

</comment></comment></comment><comment><USER20> Love the syntax 10 out of 10. Visual design wise it's not bad, but could be better. If I have some time I would love to contribute some add-one people could use for a different theme of designs.

</comment><comment><USER21> This is really nice, great job!

I'm a real sucker for simple markdown text that can be turned into something that non-technical folks can find appealing.

</comment><comment><USER22> This looks great! I wanted to do something similar to keep my site JS free, but this looks way better than what I had in mind. Thanks!

</comment><comment><USER23> Shouldn't the charts be keyboard accessible?

<comment><USER24> What do you mean by that? (I would expect that question for focusable elements, but the charts don't appear to have any focus-elements?)

<comment><USER23> This article suggests that the individual parts of the chart should be keyboard navigable:

[https://twitter.com/shepazu/status/1199053319727124486](https://twitter.com/shepazu/status/1199053319727124486)

</comment></comment></comment><comment><USER25> Nice ! For very basic bar charts the meter HTML element could be used but it is ackward to style unfortunately...

</comment><comment><USER26> .md and .css together like peanut-butter and jelly. good job :)

</comment><comment><USER27> This is really nice! Well done OP!

</comment><comment><USER28> Another JS optional charting library I've been keeping my eye on: Pancake, from the creator of Svelte.

Experimental, pre-release: [https://pancake-charts.surge.sh](https://pancake- charts.surge.sh)

<comment><USER7> _Documentation is TODO_

Why do people do this? If you're going to bother to make a project public with a big page demonstrating what it can do, why would you skip the part where you tell people _how?_

It really comes off as amateur. I have other things to do with my time than reverse-engineer your code.

<comment><USER29> _It really comes off as amateur. I have other things to do with my time than reverse-engineer your code._

Perhaps the authors, who were generous enough to share the results of their work, have better things to do than to handhold you through review of their work.

<comment><USER30> Then their work probably isn't worthwhile to adopt, given the plethora of alternatives. If their time is limited so that no documentation is produced, dropping bugfixes seem to be next (IME).

<comment><USER31> Unless those authors are specifically trying to get you to adopt their work for whatever reason (sales, good will, etc) and in which case they'd likely have documented it, you are not doing them a favor by adopting their work. You're just benefiting from what they've released.

It's like going to a free buffet and complaining there's no napkins. Sure, you can complain, and you're technically correct that there should be napkins. But it's still in bad taste.

<comment><USER30> If there is no desire to have adoption, then there is no compelling reason to host publically outside of convenience. We fundamentally agree, I think, with the difference of our thought being that we have a "show hn" post (I assume from the author?) which is an invitation to test, critique, and or adopt. Of course, the OP's relationship to the author flavors this expectation, and I could be in error.

<comment><USER32> > If there is no desire to have adoption, then there is no compelling reason > to host publically outside of convenience.

I get the sentiment, but please don't listen to advice like this. I have benefited multiple times from small Open Source projects on Github that were essentially abandoned and undocumented. Sometimes just having source code is enough. More than one of the projects I'm currently working on are essentially just forks of permissively licensed, undocumented projects that I found on Github.

Yes, documentation is very important if you want an actual professional project that lots of people can use. But I generally encourage people to get into the habit of just releasing stuff. A permissively licensed project with no documentation on Github might end up benefiting at least one or two people. Maybe it won't benefit anyone at all, but at least the possibility is there. A project that never gets released to anyone is guaranteed to benefit nobody except the original maintainer.

In general, people are bad at determining what parts of their work have value. People worry about drowning Github in tiny or unfinished trash-projects, but my experience has been that it is much easier to filter projects than to find projects.

If I have a problem, I can spend 2 hours filtering through bad solutions and reading source code until I get at least a picture of what a solution might look like. That'll be more enjoyable than spending 2 hours scrolling through unrelated blog posts or desperately trying to come up with search terms to find anything anywhere that's applicable to what I'm trying to do.

Documenting > Orphaning > Not Releasing

<comment><USER30> You know what, that is a completely fair assessment and a fantastic take. Edit period has passed, so I'd revise my prior stance to be clearer that my point wasn't advice, but more general motivation/driver assessment. In terms of what benefits society as a whole, I agree with you completely.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER33> Just so you know, that name won't fly in Europe. Google "SS" if you want to know why.

<comment><USER34> How long are we going to "ban" certain abbreviations for? Two generations? Three?

It seems absurd that a two letter combination not used for nearly a century is enough to disqualify a name on an entire continent.

We won. It's over. We can reclaim their terms and symbolism now.

<comment><USER35> Not saying it sells like hot cakes in Germany, but reclaimed for a while now:

[https://www.caranddriver.com/chevrolet/ss](https://www.caranddriver.com/chevrolet/ss)

<comment><USER36> [https://en.wikipedia.org/wiki/Toyota_Isis](https://en.wikipedia.org/wiki/Toyota_Isis)

It's even funnier because the Islamic State uses lots of Toyota Hilux</comment></comment></comment></comment>


NYT Reporter: Facebook Seeking $1 Bln in Venture Capital for Crypto Project - <AUTHOR> https://cointelegraph.com/news/nyt-reporter-facebook-seeking-1-bln-in-venture-capital-for-crypto-project/ <comment><USER2> There's no need to create a cryptocurrency around this tired old idea. In fact, doing so makes the entire system worse for users. The last thing Joe or Jane Sixpack wants to do is manage cryptographic keys. S/he's going to keep this stuff on a centralized account anyway, so why not build that product instead?

If Facebook sees a market for a bank account denominated as a floating basket of currencies, they can do that purely with centralized ledgers.

I just don't see the point of this given the deluge of similar projects already and the poor match to Facebook's mostly low technical literacy clientele.</comment>


My friends who like Donald trump - <AUTHOR> https://www.facebook.com/search/153080620724/likers/me/friends/intersect <comment><USER2> Server error 500

<comment><USER3> happened to me until I logged in

<comment><USER4> _Sorry, we couldn 't understand this search. Please try saying this another way._

Even when logged in.

<comment><USER3> That isn't the same 500 error</comment></comment></comment></comment>


Have you published research papers/technical articles?  If so, which one(s) are you most proud of? - <AUTHOR>

<comment><USER2> There are three papers which I'm really proud of:

1\. Colin Percival, Rapid multiplication modulo the sum and difference of highly composite numbers, Mathematics of Computation, Volume 72, Number 241, Pages 387-395, 2002. <http://www.daemonology.net/papers/fft.pdf>

2\. Colin Percival, Cache missing for fun and profit, presented at BSDCan '05, May 2005. <http://www.daemonology.net/papers/cachemissing.pdf>

3\. Richard Brent, Colin Percival, and Paul Zimmermann, Error bounds on complex floating-point multiplication, Mathematics of Computation, Volume 76, Number 259, Pages 1469-1481, 2007. <http://www.daemonology.net/papers/complexmultiply.pdf></comment>


On Keeping Busy and Staying Sane in Startups - <AUTHOR> http://paulstamatiou.com/keeping-busy-staying-sane-startup-life

<comment><USER2> I am happy that Paul got hooked into EDM after we started working on Picplum.

I can't stress enough how Important it is to make friends who can enjoy things outside of tech. I have had conversations with many folks at startups and they are consumed by their work. It feels like some people actually want to talk about tech and startups all the time, at work and on the weekends. I think this is rather unhealthy.

I think in a city like San Francisco we are fortunate to live with people who enjoy all sorts of hobbies and work in many different industries. This is even more true in cities outside of the bay area.

While living in Portland, I wanted to move to SF and had the urge of wanting to hang out with tech people, all the time. Good thing that never happened, luckily I had made a quite a few friends during the Mugasha days, many of them shared the same passion as me (EDM). We started going to a lot of shows together, having meals during the weekdays and even traveling around the country. This is the ultimate relaxation for me. I really did not miss talking about ruby on rails or steve jobs on the weekends.

I have to thank Portland in many ways. It's a very diverse city. It's a great place to make friends who come from all parts of the country and world.

You have to get out of your comfort zone and it doesn't matter what other people think.

</comment><comment><USER3> > hanging out with a different social circle often; ones outside of the > tech/startup world.

That's one of the things that made me happiest about moving to Italy from the Bay Area. I have a fairly wide range of friends here, some of whom are up on all the latest startup news, and others who could care less because that is not at all their area of interest. It feels a lot healthier to me that way. In the bay area, it felt like you were never really that far removed from tech; it just permeates everything. Which is cool, I guess, for a bit, but after a while I found it cloying. I appreciate having a wide range of friends here.

<comment><USER4> This also helps people to be open minded, not seeing the world from a single perspective.

<comment><USER3> Exactly. It's so easy to get caught up in doing something that impresses your hacker friends, when there's tons of stuff out there like, say, bingo cards, or, in my case, helping people format their books, that will make "ordinary people" sing your praises even if it's kind of boring from a 'cool tech' point of view.

</comment></comment></comment><comment><USER5> This is why I love living in NYC. Tech doesn't touch every corner or anywhere near it. The diversity of occupations and activities is grand. That isn't to say that the Bay Area doesn't have these kinds of activities and people, but I can go weeks in NYC without bumping into the tech scene, something that can't quite be said about the Bay Area (at least from my personal experience.)

<comment><USER6> I like hanging out with tech people who have substantial outside hobbies; it makes it a lot easier to talk about those activities (cooking, sushi, shooting, parties and DJing, video production, robots, ...) with some common ground.

</comment></comment><comment><USER7> _For us, the key to staying sane at a startup is hanging out with a different social circle often; ones outside of the tech/startup world._

I really should have done this sooner rather than later when I first moved to Ottawa. Currently living with seven others from the same incubator, in an estate right by the Kanata tech park where not much goes on for a twenty- something. It's very hard not to get engrossed in just startup and software development (design in my case) culture and this has been draining me for the past few weeks. Finally getting my act together and breaking off from the pack to do random things (BarCraft, training for Spartan Race, techno music festivals, etc.).</comment>