A better introduction to Objective-C - <AUTHOR> http://cocoadevcentral.com/d/learn_objectivec/ <comment><USER2> This is incorrect:

      - (void) dealloc
      {
        self.caption = nil;
        self.photographer = nil;
        [super dealloc];
      }

Using the dot syntax will invoke a setter whose implementation might change if the class is subclassed, which can be the cause of subtle errors. Also, if you're using KVO (Key-Value Observing), invoking the setter might notify observers who then try to work with a (partially) deallocated object.

This is standard:

      - (void) dealloc
      {
        [caption release];
        [photographer release];
        [super dealloc];
      }

<comment><USER3> Can you expand on this, as the resistance to this style has always confused me. The concern you are presenting is that a subclass could implement the setFoo method, and do so in a way that: 1) does not call [super setFoo:], and 2) does not follow the convention of handling memory management appropriately?

My problem with this argument is that the user could botch release just as well. Maybe they are slightly more likely to botch the setter, but either way they are botching it.

<comment><USER4> If you have an observer listening for changes on the "photographer" key, then `self.photographer = nil;` will send off a KVO event. [photographer release]; will not.

Since your object is likely to be dealloced at an odd time (for instance when an autorelease pool is drained), and in an inconsistent state (half its fields missing), it's much better to do a release.

<comment><USER5> Is there any situation where you would legitimately still have an observer for an object which is being deallocated?

<comment><USER6> I can contrive one. Class A holds a strong (i.e., retain) reference to an instance of class B in a property "myB". A also has a property "myC" which B observes.

      - (void)dealloc {
        self.someOtherVariable = nil;
        self.myC = nil; // Sends KVO on myC. B sees half-deconstructed A.
        self.myB = nil; // myB now is dealloc'd and stops observing A.
        [super dealloc];
      }

Admittedly this is a real edge case and probably bad design, but it's not overtly terrible. I have a couple cases where objects observe their owners.

BTW thanks for the blog, Mike! I love it.

<comment><USER5> I'd argue that this would be a bug. B has a weak reference to A here (whether explicitly or just implicitly through KVO) and that weak reference should be cleared out first thing before tearing down the rest of the object. The method should start with a [myB setA: nil], then go on with the rest. Setting that to nil would then remove the observation, solving the problem.

There may well be similar setups which aren't broken which still exhibit the problem, though.

Glad you enjoy the blog!

</comment></comment></comment></comment></comment></comment><comment><USER7> This is an excellent tutorial, especially compared to the other one. The only thing I took issue with was this:

        if ( [self hasPrefix:@"http://"] )
            return YES;
        else
            return NO;

The other thing that puzzled me a little was the K&R interfaces and Allman everything else, but I guess it's a consistent style. I do use K&R exclusively for blocks, so I suppose I am just as guilty.

<comment><USER8> What was your issue with that? It not being written as below?

      return [self hasPrefix:@"http://"];

If so, I disagree. The way it was written in the tutorial is easier to read when going into a new language — and teaches you that Objective-C uses YES and NO, rather than true and false.

<comment><USER9> I think people should not use awkward code in tutorials and then say it was for the sake of illustrating a point. Otherwise the readers can pick up bad idioms just as in a natural language. In this case I doubt the author wanted to showcase YES/NO. And if that really was the intention, you can easily add one sentence after the code example, explaining the potentially strange BOOL type and its values.

<comment><USER10> Don't confuse awkward with clever. The code that illustrates the IF conditional is far more readable than the self-returning YES or NO, where you don't even know that YES and NO are the return values.

Arguably, an ObjC programmer should know that booleans are YES and NO and not true or false, but so what? Code that can't be maintained isn't good code. Code that is developed within a team should be readable before it should be clever. if it is clever, or if it needs to be clever, then it should be commented to the degree that it is more easily understood.

I personally would rather write readable code than more comments.

<comment><USER11> > Arguably, an ObjC programmer should know that booleans are YES and NO and > not true or false

It's just C. 0 is false, anything else is true.

</comment></comment></comment></comment></comment><comment><USER12> This tutorial was how I learned Objective-C and Cocoa. Scott Stevenson's got a great and flowing writing style that's easy to follow.

Don't miss all of the other more advanced tutorials similar to this one at the full site, <http://CocoaDevCentral.com>

</comment><comment><USER13> Thank you. Really, thank you. I'm not sure why the world works as it does, but so often when I am attempting to learn or accomplish something, within a day or so something comes along that exactly matches what I need.

In this case, I had a desire to dig into an Obj-C project yesterday to try yet again to really learn it. The Apple tutorial is extensive, if verbose. This introduction is exactly what I need at this moment to get me through the knowledge gap.

</comment><comment><USER14>
        [NSString stringWithFormat:[prefs format]];

_"Avoid nested nesting more than two message calls on a single line, as it easily gets unreadable."_

Oh, the joy of function call chaining in languages like JavaScript:

        rs = db.find({"name": "Joe"}).limit(10).lower().sort();

I don't dare to imagine how that'd look in ObjectiveC ;-)

<comment><USER15> Something like:

      NSArray *records = [db find:[NSDictionary dictionaryWithObject@"Joe" forKey:@"name"] limit:10];

      [records sortedArrayUsingComparator:^(id a, id b) {
        // logic for sorting
      }];

...and then you'd do the lower method on usage...

<comment><USER16> Or even (granted that I'm assuming the whole db api here is fake, and you'd actually probably be using core data here)

      NSArray *records = [[db find:[NSDictionary dictionaryWithObject:@"Joe" forKey:@"name"] limit:10]
                           sortedArrayUsingComparitor:^(id a, id b) {
                             // sort logic
                           }];

I typically add a category to NSArray for mapping a selector or block. The signatures are \- (NSArray _)mapBlock:(id (^)(id object))block; \- (NSArray_ )mapSel:(SEL)selector;

Which would enable you to do it all in one statament:

      NSArray *records = [[[db find:[NSDictionary dictionaryWithObject:@"Joe" forKey:@"name"]
                           limit:10]
                           sortedArrayUsingComparitor:^(id a, id b) {
                             // sort logic
                           }]
                           mapSel:@selector(lowercaseString)];

Also for mapping over an array you can usually use NSArrays valueForKey: which returns a new array which contains the result of calling valueForKey: on each member of the target array. As your sorting logic would typically exist in the db layer whether you were using CoreData or something else, it would be easy to write a wrapper such that you could write something like:

      [[[[MyFetchRequest forEntityNamed:@"foo"
              orderedBy:@"SomeKey"
              limit:10] fetch]
        valueForKey@"nameField.lowerCaseString"]
        enumerateObjectsUsingBlock:^(id obj, NSUInteger idx, BOOL *stop) {
           // do stuff here
        }];

Again this is all 'fake' code as this is just a readability discussion.

I don't really agree with the article that nesting message-sends leads to unreadable code. I think reading obj-c is a lot like reading lisp s-expressions and your eye / brain quickly learns to read nested constructs. I generally try not to save anything to an explicit var that I don't intend to use somehow. (of course there are limits to this) I don't find nested code above difficult to read, YMMV.

<comment><USER15> All 3 of your examples are viable; and you're right, Obj-C isn't that hard to read once you understand the syntax.

</comment></comment></comment></comment><comment><USER17> This introduction is excellent, it's aimed at programmers who wants to get a first and painless overview on how Objective-C is coded and how to read Objective-C code. It gives you all the subtleties of the language, compared to the other (the unusual method calling syntax being the first). It's kind of a starting blocks for learning a new language, exactly what I look for when I learn a new langage.

</comment><comment><USER18> A concise presentation of most of the core features of Objective-C. It lacks protocols, however.

Apple has a bunch of good tutorials, for example this one: [http://developer.apple.com/library/mac/#documentation/cocoa/...](http://developer.apple.com/library/mac/#documentation/cocoa/conceptual/objectivec/Introduction/introObjectiveC.html).

<comment><USER19> Coming from C++, protocols vs categories still mystify me a bit.

They appear to be methods for doing multiple inheritance type stuff without the multiple inheritance problems. From what I understand protocols set a list of methods that a class implementing that protocol must provide, whereas categories let you 'tack-on' methods to existing classes.

They seem like powerful features & I'm sure there is more to them than I've described, but I sometimes have problems re-wiring my brain to 'think in objective-c'.

Seeing more tutorials that show how to use these interesting language concepts in real projects would be very educational.

<comment><USER20> Protocols are "interfaces" (in the general sense of the word in programming). So they are useful when you want to write a delegate (or callbacks in the general sense of the word) class. Many classes have a delegate property that is of type id<SomeProtocol>. Equivalent to Java's interfaces, but Cocoa use protocols heavily for delegates only.

Categories are useful not for sharing code, but for expanding a class's functionality. This is especially useful when you write a class X that works with an existing class Y, but some of X's code should be an instance method of Y, or X introduces additional capability for Y to support X. UITableView adding functionality to NSIndexPath to support referencing table sections and rows is a good example. All those Java classes that add static methods to support existing Java classes, or if you used Smalltalk and added methods to existing classes, this is the equivalent.

<comment><USER21> (I agree with you, this is just nitpicking)

>Equivalent to Java's interfaces, but Cocoa use protocols heavily for delegates only.

Uh, NSCoding, NSCopying and the million other non-delegate protocols? Cocoa uses protocols heavily for a lot of things, not just delegates. The average Cocoa/Cocoa Touch developer, however, uses protocols mostly for delegates.

</comment></comment></comment></comment><comment><USER22> Not bad but I would have liked to have seen a formal grammar for the syntax structure, especially since it is so different from Java, C# and C++ which most developers are familiar with. It was especially difficult to understand the syntax around keyword-based input arguments for methods. I only understood it on my second reading and only then because I was already familiar with the concept from LISP. There were also no examples or even mention of flow control statements. That seems like a glaring omission.

Perhaps most importantly, the tutorial should have mentioned that objective-c is a superset of c. That alone would have answered most of the questions around flow control statements since those, presumably, use the same syntax as c. As it stands, there's barely enough in this tutorial to do basic scripting with objective-c.

</comment><comment><USER23> GC and Arc will obsolete the memory management part of this tutorial but otherwise a great resource!

</comment><comment><USER24> This is a great introduction, but to this day I find the sheer size of Cocoa the largest barrier to entry for Mac and iPhone development.

Just have to get used to it, I suppose.

</comment><comment><USER25> This was a good resource when I was learning objective c. The Apress objective c book, as well as the apple documentation are also good resources.

</comment><comment><USER26> Finally someone did it! I didn't read through it yet but I definitely love the start. Thanks!

<comment><USER9> Please note that the tutorial was written some three years ago. It starts to show on some parts, for example people starting to learn Objective-C today can spare themselves the trouble of manual memory management and use Automatic Reference Counting supported by the upcoming Xcode release.

<comment><USER8> Please note that you still can't ship an app that uses Automatic Reference Counting on iOS, and we don't have any real idea of when we will be able to. Last time I had a discussion about this on HN, the other person was convinced it would have come out early September.

<comment><USER27> We have a pretty good idea. As soon as iOS 5 goes GM, we'll be able to use Xcode 4.2 (and ARC) to submit apps. With the rumoured announcement next week, iOS 5 should be GM in the next week or two.

In any case, if you're reading an introduction to Objective-C today, you're probably not going to be submitting anything to the App Store in the next fortnight.

<comment><USER28> But will apps made with Xcode 4.2 and ARC run on older iOS versions? I mean, my understanding was that ARC was a compile time thing, so there should be no difference in an ARC app and a non-ARC app (except the ARC one probably has less bugs) but I've heard others talk about needed runtime support.

<comment><USER5> ARC includes zeroing weak references, which need runtime support. These are only available on iOS 5.

The rest of ARC still needs a bit of runtime support, but the functions it needs are basically just wrappers around the standard Objective-C memory management messages. They exist because they enable various optimizations. Apple provides a shim library for these which allow ARC apps to run on iOS 4.3. I'd guess they could run on even earlier OSes, but I believe that's not officially supported.

<comment><USER28> Thanks for your answers. Does this mean we have to maintain different versions of each app or is it reasonable to say nothing earlier than 4.3 is supported [1]?

[1] Full disclosure: I haven't released my first app yet so I'm wondering if I should only develop with the new IOS 5 tools or if I'm going to have to write my app with Xcode 4.1 anyway.

<comment><USER5> This is just my opinion, so don't take my word for it.

There is no reason to support anything earlier than iOS 4.3 for an app being released today. 4.3 works on all devices except the original iPhone, the 3G, and the equivalent iPod Touch models. It's also a free upgrade for (nearly?) everybody. The fraction of your audience still using something prior to 4.3 will be very small.

If you're not releasing very soon, it will probably be worthwhile to simply require iOS 5. New OS version uptake tends to be fast, and it seems likely that those who don't update their OS are also less likely to buy apps. iOS 5 is a pretty big deal with a lot of new features, so I think it will probably see pretty swift uptake. iOS 5 also provides a lot of nice features for a developer (like those zeroing weak references, which I believe are pretty important for ARC programming), so there's a good incentive on your end to require 5+.

<comment><USER8> _There is no reason to support anything earlier than iOS 4.3 for an app being released today._

There's only one reason that I can think of: Verizon/CDMA iPhones only run iOS 4.2.x, and won't be on parity with GSM iPhones until iOS 5 comes out.

<comment><USER5> Good point, I forgot about that. I would argue that, with the small number of CDMA iPhones sold so far, and with iOS 5 just around the corner (maybe as early as next week), they can be ignored for this purpose.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER29> Is there something like this for java (for andrioid)</comment>


A Backdoor In AMD's Catalyst OpenCL Library? - <AUTHOR> http://www.phoronix.com/scan.php?page=news_item&px=MTU2OTc

<comment><USER2> Will be interesting to see what a video card backdoor can do.

capture private bitcoin wallet keys? call home when card is used to crack tons of hashes?

my bet is just a dumb name for a production line test routine.</comment>


Compulsory Licensing of Backroom IT? - <AUTHOR> http://www.overcomingbias.com/2018/07/compulsory-licensing-of-backroom-it.html <comment><AUTHOR> It's starting to look like a lot of technological advancements are purely internal to specific corporations, rather than quickly spreading to entire industries like they would in the past.

This article has one suggested solution. Alternative to what it suggests -- as noted in the addendum, there are issues with generalizing internal tools -- I'd speculate that _much_ stronger anti-noncompete rules might help more.</comment>


New Samsung Galaxy S III burns into flames, melts through casing. - <AUTHOR> http://www.engadget.com/2012/06/20/samsung-galaxy-s-iii-melts/

<comment><USER2> Non-blogspam source:

<http://www.boards.ie/vbulletin/showthread.php?p=79312161>

</comment><comment><USER3> Hope Apple doesn't sue over that "feature". ;)</comment>


Show HN: Monte Carlo ray tracer in Rust - <AUTHOR> https://github.com/Dalamar42/rayt <comment><AUTHOR> Hi HN, first time posting here!

I started this project last year when I was looking for something fun to learn Rust with and I had Peter Shirley's excellent Ray Tracing in a Weekend series of books recommended to me. In the process I got interested in learning ray- tracing for its own sake so I decided to finish all three books and I am now considering continuing this further on my own.

I am sharing in case this is useful to others who are on a similar path to where I was.

<comment><USER2> Really beautiful results. It's interesting to see Ray Tracing's durability. In the 90s it was so prohibitively expensive (computationally), that a whole bunch of techniques were developed to achieve realism in somewhat... hackier ways. Now we're seeing GPU support, etc.

<comment><USER3> Since you seem knowledgeable about this -

Can you explain what the difference between 3D graphics generated with Ray Tracing and without? My understanding is that Ray Tracing is essentially the brute force solution to the problem of lighting. We developed "hackier" approximations which run much quicker so our games can run at reasonable framerates.

Is true Ray Tracing really that much better than the approximations we've developed? Is it really worth the significant drop in performance? As an old PC gamer, I've often revered clever optimizations and approximations as not only necessary, but undeniably clever and (in my eyes) cooler.

Today it seems there's a shift in the other direction.

Now that our GPUs can just barely run Ray Tracing in modern games, people are so hyped to use it. For me, it is strange that people would clamor over graphics which are less optimized.

Is the visual benefit that high? Does a game that runs on lots of hardware like Minecraft really need Ray Tracing that requires very specific GPUs?

I guess for me Ray Tracing feels like finding the primes by naively running divisions on every number less than the one you're looking at. It's the easy solution that is terribly slow. Existing lighting engines are (perhaps) like using a sieve?

<comment><USER4> It's not just that ray tracing looks better than rasterization for the same scenario, but that some scenarios are simply impossible / impractically complicated to render with only rasterized graphics. Just one example is specular reflections with non-screen space content and a dynamic environment.

Rasterized graphics can do specular reflections quite well as long as the reflection only shows things that are currently in view. One can then perform a limited form of ray tracing in the depth buffer to detect which part of the screen is visible where in the reflection. However, as soon as we want to reflect things outside of the screen it gets tricky, as we can't simply perform this screen space ray tracing. Instead, we have to rely on pre-baked reflection map textures. This works well enough for static objects, like the environment, but you can't see dynamic content, like players, as they can't be pre-baked into the texture. Also, it's useless when there are no static objects, like in Minecraft where there's no such thing as a static environment -- every block can change dynamically. And this is where the limit of specular reflections of rasterization is basically hit. There are of course workarounds, like rendering the scene a second time from the mirrors perspective, and then combining the view render and the mirror render, but you can imagine it gets prohibitively expensive quite fast as you add a few more reflective objects to the scene. Also, this method doesn't work for glossy reflections -- that's even more complex.

So this is just one example of how rasterized graphics limits us -- we can't have more than a few reflective objects in a scene which features dynamic geometry, which is a very sensible thing to want to have!

In my opinion, ray tracing really is that much better than the approximations we've developed. Also consider how much faster / cheaper it would be for a studio to create new graphics engines when you only have to write 1000 lines of ray tracing code instead of 100'000 lines of rasterization hacks (for a worse-looking result!).

<comment><USER5> Hate to tell you this but ray tracing gets just as complicated. You're just shifting the realism bar much higher, but certain effects are always just out of reach in a given time budget and require specialised solutions and hacks to achieve.

<comment><USER4> In a given time budget, maybe, but that wasn't much a part of the question I answered. The question asker compared ray tracing to brute forcing finding primes vs. using a sieve -- and that's just not how it is.

Also, I'm not sure about "just as complicated". Is rendering refraction with dispersion "just as complicated" to achieve in a given time budget with ray tracing as with rasterization? I must admit I'm not well versed in modern rasterization hacks, but as far as I know that is simply impossible to achieve, regardless of how much time you have.

<comment><USER5> > Also consider how much faster / cheaper it would be for a studio to create > new graphics engines when you only have to write 1000 lines of ray tracing > code instead of 100'000 lines of rasterization hacks (for a worse-looking > result!).

You were talking about games here, no? That's ultimate hard time constraint.

1000 loc gets you a very basic path tracer which isn't really going to be good for very much.

Your dispersion example is interesting - you can't really do it correctly with rasterization, no, although you can do a distorted background texture lookup with individually offset/blurred RGB channels. If you want to do rough glass you can just increase the blur amount. Not correct but looks 'good enough' in a lot of cases.

With ray tracing you can just trace 3 rays (one for one for each of red, green and blue). Simple! Except can you really afford 3 rays? Also how much do offset them by? You could use Cauchy's formula and use real refraction indices, but then you're going to get ugly separation between the channels. You could sample the whole visible spectrum and use temporal accumulation to build up the correct color, but now you've got color noise. What happens if you want to simulate rough glass? That's going to be very noisy indeed.

What about shadows from the glass? You can't afford to render caustics to do it correctly after all. Do you just ignore them? That'll look weird. Use a fresnel-weighted transparent shadow? Probably but now you have to handle that correctly everywhere and running a shader for shadow rays is expensive too so maybe you have to special-case that situation so most of your scene lands on the happy path.

My point is that anyone can write a basic path tracer in a weekend that will correctly simulate light transport given an infinite amount of time. Writing a renderer that will produce an image of a given quality in a given amount of time, incorporating a list of effects that an art director has decided are essential to the look of you product, is a very hard task still. It's simpler in a lot of ways, but also has to handle a lot of other complexities for the things that aren't possible in a rasterizer but are still very expensive to compute in a ray tracer.

<comment><USER4> You make many good points, but I still feel like you're really underselling the potential of simple ray tracing. Hardware acceleration of intersection testing and BVH construction/traversal is only going to become more prevalent, and with temporal reprojection and spatial denoising methods, many kinds of noise can be mitigated. It doesn't even have to be that complex -- "An Efficient Denoising Algorithm for Global Illumination" by Mara et al. is only 7 pages (more like 5, really).

Regarding spectral path tracing and colored noise, Wilkie et al. have written a good paper on this, "Hero Wavelength Spectral Sampling", if you're interested.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER4> I'll chime in with my own ray tracer! [https://gitlab.com/JoJoZ/futhark- tracer](https://gitlab.com/JoJoZ/futhark-tracer)

It's a spectral path tracer written together with my friend as part of our master's thesis. It's implemented in Futhark, which is a new language for GPU programming. It's a purely functional array language, and it's very ML-like. It makes GPGPU programming quite easy, and as far as we can tell, the optimizations are really good!

</comment><comment><USER6> For those looking to go beyond Pete's "in a weekend" book, the full text of the 3rd edition of PBRT is freely available online:

[http://www.pbr-book.org/3ed-2018/contents.html](http://www.pbr- book.org/3ed-2018/contents.html)

</comment><comment><USER7> Great work.

You might be interested in checking out the implementations of pbrt in rust too

[https://github.com/wahn/rs_pbrt](https://github.com/wahn/rs_pbrt)

<comment><AUTHOR> That's interesting. Thanks, I'll have a look

</comment></comment><comment><USER8> How do you get it so clean? My renders have artifacts no matter how high I crank up the fidelity: [https://github.com/brundonsmith/raytracer](https://github.com/brundonsmith/raytracer)

Edit: I just zoomed way in and I can see ever so slight bits of speckling :) Maybe I'm just not turning the bounce-ray count up high enough...

<comment><USER6> The author is actually preferentially sending samples towards "attractors" [0] for lights and dielectrics. Doing so massively reduces variance. My favorite example is Figure 5 in this old paper [1] (I've never actually read Pete's ray tracing in a weekend, so I don't know if this is in there).

The most common variance reduction technique though would be to do direct lighting (aka "next event estimation" if you want to be overly pedantic). Your lighting in that image looks like it's just a "Hi, I happen to be emitting tons of energy" sphere in space, which will cause a lot of noise. Alternatively, if you _are_ sampling it, you are likely not sampling the sphere as well as you could. You'll want to sample the sphere following the setup in Figure 2 in Pete's "Direct Lighting" paper [2] (which as a reminder, is currently accessible at the ACM during Covid-19).

[0] [https://github.com/Dalamar42/rayt/blob/fc57fa4afc080a578e21e...](https://github.com/Dalamar42/rayt/blob/fc57fa4afc080a578e21ececb153e6d717c9459f/src/world/materials/mod.rs#L103)

[1] [http://graphics.stanford.edu/~boulos/papers/gi06.pdf](http://graphics.stanford.edu/~boulos/papers/gi06.pdf)

[2] [https://dl.acm.org/doi/10.1145/226150.226151](https://dl.acm.org/doi/10.1145/226150.226151)

<comment><AUTHOR> The 3rd book [0] is primarily about implementing an MC ray tracer and then adding the techniques in the second paper you linked. That's what I've used in my code as well. I just skimmed through the paper and I think the book covers most of the material from the paper with the exception of spatial subdivision. I will have a more careful read later to see exactly what my implementation is missing from this.

[0] [https://raytracing.github.io/books/RayTracingTheRestOfYourLi...](https://raytracing.github.io/books/RayTracingTheRestOfYourLife.html)

</comment></comment></comment><comment><USER9> Here's my version: [https://github.com/peterbraden/rays.rust](https://github.com/peterbraden/rays.rust)

</comment><comment><USER10> Hey, could the readme provide a list of how far along this project got (i.e. material types, object imports, textures, optimizations for collisions)?

<comment><AUTHOR> Hey. At the moment what is implemented is exactly what you are going to find in the three books of the Ray Tracing in a Weekend series. If I can find the time to continue this project, I am going to make a git tag for the current version for people who just want to use this while going through the books and I will also add a changelog for any changes I make from that point onward.</comment></comment>


Am I victim of offering too many features to users? - <AUTHOR> http://rivals4ever.com

<comment><AUTHOR> Am I making user confused by offering too many things here? Should I remove some features such as Passion Talk, News etc from Rivalry Detail page?

<comment><USER2> I don't think that's the problem here. I think the bigger question is with the premise of the site: why, exactly, would I want to "debate" Coke vs Pepsi, or Arsenal vs Manchester Utd?

Clearly, I'm not your target audience-- but the fact that most rivalries have less than 100 users seems to indicate that you're not hitting your target audience, whoever they might be, if they exist.

<comment><AUTHOR> makes sense.</comment></comment></comment>


Tesla to Buy Energy Storage Firm Maxwell Tech at $4.75 a Share - <AUTHOR> https://www.bloomberg.com/news/articles/2019-02-04/tesla-to-buy-energy-storage-firm-maxwell-tech-at-4-75-shr-value <comment><USER2> I miss the full power regenerative braking when using my Tesla in the cold. Like, I really miss it and don't like driving the car as much when it just coasts when I lift the accelerator.

I actively dislike pressing the brake pedal anymore, and feel cheated whenever I have to touch it except to activate Hold at a stop.

If supercaps could give me full regenerative braking at 0°F then I'd pay an extra $1-2k for the feature absolutely.

In warm climates I can absolutely see brake pads never being replaced. The only time I use the brake pads to slow down is in sub-freezing temps and once in an emergency.

For those who haven't driven an EV with strong regen braking, you drive with a single pedal. "Neutral" is the accelerator slightly depressed. Lift your foot to slow down, fully lifting your foot is a _strong_ braking down to about 10 mph. I should look up how fast you get 60-10 with a warm Tesla on regen alone. You drive with a single pedal, and you can dart in and out of traffic very nimbly because over-accelerating for a lane change and then regen'ing back to cruising speed is very efficient and fun and you don't have to move your foot to another pedal. But regen degrades as the battery cools.

A frozen battery will barely regenerate at all, at 0°F it's actually disconcerting when you lift your foot and the car just... coasts. The display does have a gauge showing how much regen is available, so it's not a surprise but it literally feels weird.

<comment><USER3> To each their own. I like my TM3 and enjoy regenerative braking but there really is not reason to use a blended braking system which keeps with the current petrol car model of, use the brake pedal to slow down. It also may be safer since your foot will be over the brake when needed.

Chevrolet used this on the Volt for normal driving, you press the brake pedal and it decides how much hydraulic brakes you need over what regeneration can provide. Audi is going this route too. What makes it even better is they can totally mask the loss of regeneration in cold weather which can be disconcerting.

If anything I think Tesla should make it an option, the loss of regen braking even when the pack is only saturated to 40F is bad enough and just useless below freezing. They can do wonders with OTA so there is no reason to not offer all options, low to regeneration, high regeneration, maximum, and blended.

Again, blended doesn't mean it uses the disc brakes, only that it can when it has too and this is safer than relying on one pedal driving.

<comment><USER4> Your point about safety raises an idea: Why not do the inverse? Your driver assist tells the car how fast it can drive (GPS, signage), break pedal as well as a configurable level of assistance tells it how much to stop. Steering is still mine, and I won't give it up until full autonomous cars with zero driver responsibility are mass produceable.

<comment><USER5> There's a lot more to how fast you can drive than GPS and signage. There's also weather, road conditions, if there's parked cars hurting visibility along the road, whether there's pedestrians near the edge of the road (especially children who might dart out quickly), etc.

You have to slow down to turn, too. I can't imagine a situation in which you could let speed be outside the driver's control entirely.

<comment><USER4> Yes, therefore you either

a) break yourself on turns, pedestrians waiting, even red light etc.

or

b) choose to let driver assist take over some of these tasks from you

the whole idea is that instead of doing one-pedal driving on the accelerator it's safer to do one-pedal on the break.

</comment></comment></comment></comment></comment><comment><USER6> This is a smart move by Tesla, Maxwell's supercap technology is a really good way to moderate power needs and to extend range.

It also seems like the first step in the "Okay, we have the basic system that works, lets start knocking off the biggest problems with it." mode that internal combustion cars have been doing for the last 100 years.

<comment><USER7> I dunno, I could be using them wrong but I have not been impressed with their (or any) supercapacitors. At the 1000s of Farads, they seem to bleed charge like crazy, and it gets a lot worse when they need to deal with mechanical shocks and vibrations, even the "durablue" ones.

Their low voltage also makes them hard to use; you need to balance them, and their capacitances vary considerably. Most range from -20/+80% to -10/+20%, but I guess big customers have options to deal with that. Still, if your battery pack is 300+V, and your supercapacitors can only charge to 3V...that seems difficult.

I used to be really bullish on them for regenerative braking - I think some kinds of buses do use them for that - but having tried to use them, I can't see them being robust enough for consumer, and especially consumer automotive, requirements in the immediate future.

Also, it's on the order of 10x the cost for similar capacity to lithium chemistries, and that comes in a package that weighs on the order of 10x as much as a similar battery.

But hey, I'm just a layman. It sounds like you probably know more.

</comment></comment><comment><USER8> Here's my first thought: Put both supercapacitors and batteries in an electric car. The supercapacitors can help greatly in a couple of ways. When doing a fast charge, the supercapacitor bank can absorb the energy super fast, much faster than a bank of batteries could. Then a microcontroller could control the transfer of that power more gradually over to the battery. (Unfortunately, super capacitors, when I last read something about it, could only hold their charge for 4 days or so, so they couldn't replace batteries themselves.) Perhaps this could be the key to the 5 minute recharge for cars?

Second, supercapacitors could also save some wear and tear on the batteries during rapid acceleration and regenerative charging.

<comment><USER9> For a capacitor to be used in charging that way it would have to have something like the same capacity as the car's battery. Supercapacitors tend to have lower specific energy density than batteries do so this would require reducing the car's range by something like a factor of 5.

A capacitor much smaller than the batteries acting as a buffer for rapid acceleration and braking might make sense, though.

<comment><USER8> _For a capacitor to be used in charging that way it would have to have something like the same capacity as the car 's battery. Supercapacitors tend to have lower specific energy density than batteries_

I was under the misapprehension that they had a much larger energy density. However, my next thought is that not all charging is the same. Only the 1st 60% of a charge is in the constant current part of the charge curve. After that, the charge rate falls off. Charging the last 10% of a battery's capacity takes much longer. What if the supercapacitor bank had about 10% of the capacity of the battery? That would still be a large increase in the size and weight taken up by energy storage, though. It looks like just putting more batteries in the car is the economical thing to do.

<comment><USER9> In general capacitors have much higher power density but much lower energy densities than batteries and supercapacitors are somewhere in between.

[http://large.stanford.edu/courses/2012/ph240/aslani1/](http://large.stanford.edu/courses/2012/ph240/aslani1/)

Using a capacitor for the last 10% might make sense, or it might not. It's all about the specific numbers. It might be that a larger battery charged up to 90% might be better than a slightly smaller battery charged to 100% with the assistance of a capacitor. If you're adding a capacitor for power reasons anyways this might be a way to get more use out of it.

</comment></comment></comment></comment><comment><USER10> It's interesting. Maxwell has been around for decades. Publicly they were known for ultracapacitors (non-expert opinion is that this would be a sweet spot for regenerative breaking capture in Teslas). But seems like nothing worth acquiring the company over - there are other vendors and they could just set up a multi-year supplier contract.

There are some articles/rumors out there about dry electrode battery tech Maxwell was working on.

<comment><USER11> > There are some articles/rumors out there about dry electrode battery tech > Maxwell was working on.

If this acquisition included any breakthrough-level battery technology, it'd be for far more than $218M as it probably would have involved a bidding war considering the stated electrification plans from all major auto manufacturers.

<comment><USER10> Why do you think Tesla acquired Maxwell, then? Why did Maxwell sell existing lines of business several months ago to focus on the dry battery tech and ultracapacitors?

I don't know enough about dry battery electrode tech to know how much progress there is, how much an of an improvement they are above existing commercial technology, or who else has IP in the space.

Your response seems a bit high on the cynicism/information ratio, but I would be genuinely grateful for more information about this.

<comment><USER11> I persume it's to bolster their battery tech and R&D dept. It just doesn't seem like anything obviously game-changing from where I'm sitting.

</comment></comment></comment></comment><comment><USER12> This seems to make more sense for optimizing 0-60mph acceleration metrics than just about anything else. Using SuperCaps, a base Model 3 could have the 0-60 times of a P100D for much less than the cost of the required batteries.

4WD off road vehicles could also have much higher torque for brief periods of time.

<comment><USER13> While true, I think cold temperatures might be the more applicable scenario. When the batteries are cold, the amount of power you can extract is limited, as is the amount of power you can inject by regen braking. This is one factor that leads to crappy range in cold climates.

Capacitors can smooth out the power curve - need 1000 amps of current for 4 seconds? No problem, that comes from the capacitors and the battery only sees a draw of 200 amps. Need to regen 600 amps for 15 seconds? No problem, dump that into the capacitors and recharge the batteries at 50 amps for the next minute.

Knowing Tesla, they will use capacitors to offer both; a super-plaid mode that can supply 1800 amps momentarily, as well as better cold weather performance.

<comment><USER12> Can you market the cold temp regen? Maybe? Can you market 0-60 numbers or 4wd capability? Absolutely. Which one is sexier? I think Elon would say the performance numbers.

<comment><USER14> There is literally no reason why they have to pick between the 2. It's one system that can do both depending on the situation. Some countries/areas will care more about the cold temp regen and some other markets will care more about 4wd or the 0-60 performance. The great thing about EVs is that you can just redirect power to whatever you need at any given time.

</comment></comment></comment></comment><comment><USER15> Ok we know that ultra-capacitors carry about 10x less energy/kg than current li-ion batteries.

This means they have limited use in small consumer cars, other than maybe helping the brakes or conditioning power. What they lack in weight, they make up in charge/discharge times.

Being that a truck weighs multiple times more than a sedan, it's batteries are unlikely to absorb regen braking. So a small capacitor bank makes sense. A large capacitor bank would be useful if the truck was using overhead charging cables for a small section of the road. Or if a public transport bus was quickly charging between every few stations, it could then function all day.

The large weight of the capacitor bank isn't a problem if it's used in a charging station, where 3-phase 400+ volt power may not be available. This means that any level 1,2 charger can be upgraded to a level 3 without needing to dig any trenches, further improving the user experience of the car owner and reducing range anxiety to a minimum.

</comment><comment><USER16> The cars already have heat pumps in the form of air conditioners. They could be designed with minor modifications to also be used for heating, improving the energy efficiency of cold vehicles a lot.

</comment><comment><USER17> Why do journalists always change units? Usually they report a sale by valuation but with price per share I first have to look up the company and find the number of outstanding shares.

<comment><USER18> It's journalists' job to highlight what's noteworthy, and in an acquisition it's not always the valuation of a company. In this case, the price per share is headlined to highlight the premium (55%) Tesla is paying for Maxwell Tech's shares.

</comment></comment><comment><USER19> Can these capacitors be used in any way for faster charging of the car? Like have a capacitor bank pre-charged and then unload it into a car for much faster charging.

</comment><comment><USER20> I hope this doesn't affect the supply of Maxwell supercaps in the overall market. It really is star trek level technology.

</comment><comment><USER21> Why is this newsworthy, other than Tesla is acquiring a micro cap company in an all stock offer? There's not even a blog post on Tesla.com or a tweet by Elon regarding Maxwell.

<comment><USER22> Because Maxwell is a fairly popular name in the field; and this is interesting for hackers...

</comment></comment><comment><USER23> Certainly more fuel for the fire with Tesla bears, given that Maxwell has been in trouble with the SEC on multiple occasions for financial shenanigans:

[https://www.sec.gov/news/press- release/2018-48](https://www.sec.gov/news/press-release/2018-48)

[https://www.sec.gov/news/press/2011/2011-31.htm](https://www.sec.gov/news/press/2011/2011-31.htm)

<comment><USER24> Is Musk pulling this to try and distract attention from the sales estimates in Jan 19? It's looking like an enormous, enormous plunge.

<comment><USER25> I don't think so. The China Gigafactory news was enough to silent many of the shorters and Tesla critics.</comment></comment></comment>


Software Architect – A Role, Not a Job - <AUTHOR> http://spin.atomicobject.com/2015/02/19/software-architect-role/ <comment><USER3> Besides, when I hear someone referring to themselves as "I am an architect" (in the context of software development) I usually read between the lines as "I have a rather inflated sense of self and am quite susceptible to flattery".

It is kind of like the milder version of Rockstar or Ninja Developer.

I know it is an official title in many organizations (unlike say titles like "Rockstar Dev IV"), nevertheless, it still sounds a bit silly to me.

<comment><USER4> I was getting ready to undergo a surgical procedure once. The doctor looked at my chart and saw I was (by title) a "software architect". He asked me to clarify. I described what the job entailed. He scoffed, "So you're not a REAL architect," as though I were inflating the title my organization had given me.

Didn't really give me any reassurance as he wielded the knife.

<comment><USER5> Well, your doctor did have a point. In most countries, "architect" is a protected title. Architects are required to register and they must meet very specific requirements. If a hardware repairs guy adopted the title of "Doctor of Computer-Medicine", I think most of us would find it silly.

Personally I agree that we should let real architects keep their title rather than muddy it with the confusing baggage of our business.

</comment></comment></comment><comment><USER6> IT over the last 10 years has been a story of breaking down siloes.

Agile development was all about breaking down the wall between IT and the business - getting them collaborating earlier and more often.

TDD and test automation are bringing development and test closer together, getting testing involved earlier in the cycle and quality build in.

DevOps is bringing the build and run halves of the IT organisation closer together, breaking down that particular silo.

All of the other siloes need to go the same way - infrastructure, information security, architecture. Siloes were great for a waterfall world, but when we want to move quickly the whole concept of functions and job titles is too slow and process driven.

What I'm trying to say is, yes, I agree with this post whole heartedly.

<comment><USER7> Information security seems like it has especially never worked well as a silo. Without building it in proactively at the beginning and continuing to design with it in mind, software quality wrt security will always suffer badly.

Unfortunately the stark reality is that for almost everything, worrying about security means you ship things slower. It's not that people don't know they need to worry about it, it's that every short term incentive exists to shove it aside. And so people have, and do. Security doesn't drive user growth. (It can make people go away eventually. But it almost never drives adoption.)

There's a real tension between "move fast and break things" and "break down all the silos".

</comment></comment><comment><USER8> > In the same way that ex-engineers often struggle to let go of the code when > they switch into management, I've seen the same thing happen to those > switching to architect roles

It's not always a choice; where I worked, as architects we sometimes had to put on our hero-capes and wade into code to save the day.

Saying "that's an implementation issue" doesn't work when the implementers don't have the savvy to make it work. Or, worse, throw up their hands and say it's impossible because of the unreasonable demands of those ivory-tower architects . _Can 't we just save the credit card details to a local database instead of all that integration stuff?_

At the end of the project, if it works it's despite the architects and if it fails it's due to the architects... always in the spotlight but never in the limelight.

<comment><USER9> > It's not always a choice; where I worked, as architects we sometimes had to > put on our hero-capes and wade into code to save the day.

I think its a matter of context, and one "architect" from one organisation to another will differ greatly.

I've never seen a good "hands-off" architect in my experience. They've normally been the failed developers, or the ones that have been able to network to such an extent they get to a hands-off role. But, that's in context. Dilbertian almost.

<comment><USER10> >I've never seen a good "hands-off" architect in my experience.

Because when it's done right, coding is 80% "architecting" stuff. If there is more than a tiny amount of menial work involved in programming then you are generally doing something very wrong.

I think architect is one of the worst metaphors to ever grace the software engineering profession, by giving this impression that a programmer who can work "hands off" is even possible.

<comment><USER11> >>Because when it's done right, coding is 80% "architecting" stuff. If there is more than a tiny amount of menial work involved in programming then you are generally doing something very wrong.

I both agree and disagree with this, or it may be that the statement is vague (or that I just don't understand it).

I have seen horrible "analysis paralysis" at most of the big financial institution where I have worked - especially the ones with a separate "architect" job. Hundreds of UML diagrams that were worse than none.

For myself, I actually _understand_ problems better by coding them. I can't always say exactly how something will work until I _do_ it. Once I have general idea defined, I just start coding it!

This is not to say that I sometimes don't put pencil to paper to help me think it through, but I would say I spend _far, far_ more time coding than thinking. In fact, for me, coding _is_ thinking. Yes, there is rewriting and throwing away and revising and tightening that inevitably happens. I work more like a writer, I suppose.

This may not be everyone's cup of tea, but it's how I work. There is a balance to these things and it's up to everyone to figure out where they fall.

<comment><USER10> This sounds more or less exactly like what I wrote. What part did you disagree with?

<comment><USER11> I may have read it wrong.

I would have said: "Because when it's done right, 80% of "architecting" stuff _is_ coding."

If that is spirit of what you are saying, then I got it backwards! (apologies)

Edit: I think I see the problem. There is an "of" missing. "Because when it's done right, coding is 80% _OF_ "architecting" stuff."

</comment></comment></comment></comment></comment></comment><comment><USER12> But here's the thing - dedicated architects often aren't just focused on software. The same architecture patterns you use for building software are just as applicable to business processes or organizational design. Architecture as a function has been consolidated to ensure effectiveness across all parts of the business, not just software development (which is why it's often called enterprise architecture or solution architecture).

A good architect should work WITH the software experts to determine the optimal architecture, but sometimes the business needs will require an architecture that is less optimal than it would be in a vacuum. In organizations large enough to require a dedicated architecture function, software developers are poorly positioned to understand the various requirements of the architecture.

<comment><USER13> If an organization has grown so large that software developers do not understand the larger business and organizational requirements, then that organization has already gone too far down the path of compartmentalizing their teams, at least in terms of job satisfaction and career growth for the devs.

When I worked in medium sized organizations (4000 employees, etc), we did have devs who did not understand the business, but they were outsourced contractors. Every actual employee knew the broader picture of their own applications. Those of us who worked on platforms that pervaded the enterprise did have enough knowledge to make architectural decisions. We also knew enough to pull in other people when a decision stepped outside our area.

After a few years, a new CIO did form an enterprise architecture group, and hired a new guy to be the "enterprise architect". We were told that software devs need not apply. Morale died, projects started to go very badly, and within 2 years everyone had quit.

So while there may be organizations that really do need a separate enterprise architect, I'm pretty much on board with the article, and feel that those places are likely to be quite craptastic places to work.

<comment><USER12> I agree - they're not the kinds of places that engineers who love working in a startup would enjoy. But if you're going to scale as a company past a certain size, you have to centralize these functions, which is why large enterprises are such a pain in the ass to work for. If you don't centralize the architecture functions, you start to get multiple independent groups building the same things because the communication is too hard to manage across a big organization.

Enterprise architecture is a totally different skill set from software development - it requires a business mindset, not a technical one. It's really more a requirements gathering job than a development one, and it wouldn't be enjoyable to most developers anyway. It's one of the inflection points that growing companies have to deal with - the people who built the company may not be right to maintain it going forward. The job becomes more corporate and less fun, and growing companies often see a lot of turnover during these times. But some people will stay on, as job security to support a growing family becomes more important to a developer than fun projects or the content of their work.

<comment><USER14> A large part of why different teams end up building the same thing is it's not actually the same thing. The details are frequently different is subtle but important ways.

Often building a single piece of software to assist 4 teams is several times more difficult than simply rewriting that code for each of the teams. Sure, that's not always true, but for such generic needs you can generally use or start an open source project.

IMO, the best of both worlds is to have an architecture team that approves designs created by a developer team. Ego often gets in the way, but the advantage is 'Architects' can keep track of wider segments of the organization when you treat them more like building inspectors than building Architects. With the added advantage that they can help teams cross pollinate vs. trying to come up with an ideal design in a vacuum.

<comment><USER12> Totally agree -- but the job function of the architect is different than that of a developer. Usually the architects are more concerned about architecture patterns and intercompatibility, i.e. making sure everyone is using the same messaging bus, same primary keys, etc. Hence my comment that architects should really be defining some base technical requirements, but leave most of the internal implementation details up to the dev groups.

</comment></comment></comment></comment></comment><comment><USER15> I think the arguments for or against keeping full time architects on staff versus having developers who also work together to design out systems are the same the argument for or against separating out internal systems and test automation from regular developer roles. For example googles SET, STE & Engineer roles.

Personally I like more integrated teams and believe a good architect should be down in the mud writing code half the time in-between designing things out. Partially because technology keeps changing and you need to keep an eye on developments and partially because it's a shame to waste that big picture understanding when tacking debugging or designing out specific components, and partially because it's important to keep an eye on cod equality.

I've done the architecture thing both ways however, throwing design notes over the fence versus designing and helping with implementation, and honestly they both have their pros and cons.

Tighter integration reduces communication problems and wasted effort. On the flips side having individuals focus on producing what they produce best can be more efficient then forcing team members to wear multiple hats. For the same reason why a country much better at growing expensive widgets and slightly better at growing gaskets than another country should focus their production efforts on widgets while the other country focuses their production efforts on gaskets.

The major problem in my own humble opinion with the separating out the architecture discipline is that once you step away from the code you're basically kicking off a countdown to the point where your understandings of the technologies involved and current practices and tools doesn't match up with reality. Which impacts your quality as an architect.

You can say similar things about technical project managers, general managers and ctos who no longer code,

</comment><comment><USER16> At the place where I work, I've recently described the role of Software Architect. It is a project-role, so only exists in the context of a project, and usually only in the first weeks of a project.

We describe it as follows (feedback is very welcome):

# What is expected of a Software Architect?

* Makes high-level technical design choices.

* Records those choices, and the supporting arguments, in a deliverable.

* Ensures feasibility of the technical approach (and informs the PM).

* Identifies risky aspects of the project (and informs the PM).

* Dictates technical standards (e.g.: coding standards, tools, frameworks, platforms).

* Provides the team with a "standard way" to develop the software.

* Ensures compatibility with Hoppinger's technical road map.

* Aligns all his decisions with the resource constraints of the project.

* Recognizes "reuse" opportunities (either existing software that can be incorporated, or spin-off contributed/reused).

* Observes and understands the broader system environment (of the customer).

* Creates architectural overview diagrams and/or descriptions when needed.

* Knows which applications are used in the organization.

* If possible: subdivide a complex application, during the design phase, into smaller, more manageable pieces.

* Understand the functions of each component within the application, and the interactions and dependencies between components.

* Communicate the technical design, "architecture", to developers.

* When needed also provides hardware requirements (or several options), considering the needs and abilities of the customer.

<comment><USER17> This is pretty much the description of an Architect that the article is arguing against.

From my experience, Architects that conform to the above requirements tend to sit in their Ivory Towers and are oblivious to the problems on the ground.

<comment><USER18> > ...and are oblivious to the problems on the ground.

Should they even care, if it's not their role? Engineers are hired to problem solve, architects are hired to design.

Think about an architect designing a building: should he/she know the intricacies of every separate sub-system in the building (plumbing, wiring, ventilation, gas...), or rely on experts in each of those sub-systems to resolve implementation issues? The architect is only concerned with pulling together all of these separate efforts to form something cohesive and elegant.

<comment><USER19> Not many buildings would stand upright if what you said was true.

An architect absolutely needs to be on top of the technical implementation of both ventilation, fire systems and plumbing. They won't be the ones who installs them those things are taken into consideration when the plans come together. If you think an architect only dreams up what it should look like and then leave the project you are mistaken.

With that said, I think a building architect is a terrible metaphor for what's done in software engineering for plenty of other reasons.

And yes, you absolutely need to have intimate details of how the coherency protocol works if you are the software architect of a clustered system, just to take an example. In the opposite direction lies disaster (which I've seen first hand).

</comment></comment></comment></comment><comment><USER20> Agree, but I would go further. The term "software architecture" is one I actively disdain. Architects build buildings. If there's anything we learned from comparing civil engineering to software development it is that they it is harmful to draw parallels. So while using architectural metaphors is sometimes ok, this term is not.

Software design, on the other hand, is something everyone who writes software is involved with. It is not an act reserved to few and disseminated to the "great unwashed coders" like they are some kind of construction crew who just read blueprints while typing the source (another crappy parallel drawn from the same place as the term 'software architecture')

<comment><USER21> I disagree, but I also agree.

I believe software _can_ be planned to near-perfection by one or more architects. If you establish a design, the implementation can be verified, at least to the level of detail defined in the plans.

In my experience, the problem is that I find coding to be a bit tedious. Problem-solving is the interesting aspect of software development, and when that gets taken away my productivity drops. I'm sure not all developers feel the same.

A great engineer knows their colleagues well enough to delegate effectively.

<comment><USER10> >I believe software can be planned to near-perfection by one or more architects. If you establish a design, the implementation can be verified, at least to the level of detail defined in the plans.

^^^

I'm sorry to say that this presumption right here is responsible for an awful lot of the terrible code I've seen.

Doing architecture isn't like solving an equation.

Architectural decisions are nearly always trade offs and the worst trade offs are made by people who believe that there is a Perfect Answer to problems that have no one one right answer. They have a tendency to get religious about approaches, technologies, languages, etc. (sometimes even text editors and where to put the braces).

<comment><USER21> Perhaps near-perfection was a poor choice of language. My point was that a software architect could design a complete solution without writing any code, and be very confident that it will work as required when implemented. In many organisations waterfall is too expensive/slow, and often an early iteration is more important than a robust implementation. But the waterfall methodology is still the only option for mission-critical applications. And these systems are best designed by experienced software architects before any code gets written.

I'm not saying that the architect's involvement should end after design. They are critical to communicating the design to anyone involved with the implementation phase.

</comment></comment></comment></comment><comment><USER22> I don't like the term Software Architect. I think having an architect for software alone is redundant. That's part of the job of coding.

Where I believe there _is_ value is in having a _System_ Architect, who will take a wider view of the system as a whole, especially wrt the users and how they will use it, plus all the add-on mechanisms required to install/maintain/backup a production system.

</comment><comment><USER18> > One risk of the integrated architect model is that an architect can get > preoccupied by implementation.

Nailed it. In the same way that ex-engineers often struggle to let go of the code when they switch into management, I've seen the same thing happen to those switching to architect roles. They find it hard to step back and trust others to take care of the implementation, and this often leads to the worse kind of micro-management tendencies manifesting early on in this transition period.

The best architect I ever worked with was a terrible programmer (by his own admission, and I can confirm because I worked on fixing his code). But he was able to bring to bare tremendous technical improvements on any project he worked on. It's a different mindset, more focused on the design of the implementation rather than the actualization, and it's really not suited for every ex-engineer (just like management).

</comment><comment><USER23> We have no architects. Everything is design-by-committee, and the design is horrible. It wouldn't matter if we had them. The business believes iterating on the business plan and direction is agile development, the result being a code base full of dead ends and code that should be refactored or deleted, but can't because it will take a non-trivial effort to do so since data is already deployed to production. If we ever do take the time to clean up, that's a sprint the business doesn't get any backlog items, so those sprints are few and far between.

<comment><USER24> > _The business believes iterating on the business plan and direction is agile > development_

The perils of Agile. You are only allowed to do what you stakeholders understand. The rest is ignored.

<comment><USER25> > The perils of Agile. You are only allowed to do what you stakeholders > understand. The rest is ignored.

Sounds like quite a passive aggressive way to solve a communication problem. "You only said we needed feature X, you didn't tell us not to mess up our codebase during the process".

It's not the stakeholders responsibility to tell you how to do your job. You don't wear clothes at work because it's in the backlog, you do it because it would be unprofessional not to.

Even when stakeholders have asked me to take shortcuts, they usually seem very level-headed about it once you start the dialog.

I've talked to stakeholders proactively about tradeoffs of taking shortcuts and they seem to understand when I compare "not refactoring" with "making a mess". In my experience, people understand what messes are.

If we make a mess, it will slow us down as long as it is there. We can clean it up later, too, but it will cost us more because it is slowing us for a longer time.

Taking shortcuts without telling stakeholders is unprofessional. If the stakeholders don't explicitly tell you to not refactor, refactoring is implied.

<comment><USER24> What do you expect from a method that is based on _visible results_ for _short term_ iterations (a.k.a. sprints)?

<comment><USER26> Hardly anything in software is literally visible. Wouldn't visibility be an analogy for clear and tangible?

With enough communication any result can be a visible one because everybody understands why it is important.

</comment></comment></comment></comment></comment><comment><USER27> I've always viewed software architecture the same way start-ups function. If you plan to build frameworks, guidelines, and processes, you should treat those things within your company as a new product or service. Your customers are all of the programmers, some of the business liaison people, and stakeholders of the systems within.

If you build a framework and approach your customers for buy-in and they refuse, you've failed. And failure is as simple as having complicated documentation, extended ramp-up periods, or high turnaround in your development teams.

Know your customer. Get their buy-in before you complete any big changes. Don't assume your brilliant ideas will be received or successful, no matter how great they may be.

</comment><comment><USER28> There's a comment on that post that I 100% agree with. The architect is responsible for the architecture (among other things) but that doesn't mean she's doing all the work. It's a team effort. The artchitect is just the one who is responsible for the final deliverable. Same with every role. It's defined by it's responsibility, not necessarily by the work being done.

</comment><comment><USER29> It's certainly true that if someone in a an architect position does not know the technologies intimately then how can they make informed decisions about it.

They can certainly maintain consistency at a high-level e.g.this next solution will have a REST API, but people still shouldn't be making those decisions without a detailed understanding of the impact of those decisions. I have seen devs move into a pure architect role but as time goes on it does become apparent that they need to be closer to the detail.

I think the definition of architecture should be a dev team effort with the architect role making the final decision (be that lead dev, CTO, whatever job title for that person).

I like the idea suggested in the thread of making the architect a product team/project role.

<comment><USER30> An architect, at least one worth his title, does not work in isolation.

The article talks about a type of architect that I call tech lead. It has as much to do with the architecture process as a front-end developer has to do with mechanical engineering.

There are many types of architect, with vastly different roles and functions within an organisation from pre-sales to business strategy so I strongly argue that people should stop looking to become architects as a step up from being engineers in the same way that fashion models should stop looking at picking up acting as some sort of a graduation when when they get too old for the catwalk.

Some can do it because they have picked up enough knowledge and insight along the way but, for most, it's a new career with a whole new set of skills and responsibilities.

<comment><USER29> An architect needs to keep learning in much the same way as developers do. I would look to this person to make the decision on the high-level system design/architecture for each solution. I think they should also be pushing the dev team to look at new tools and technologies, and it would really help if they had some understanding of those technologies.

I think there is a similar debate (but from a different angle) around should your project manager or scrum master be technical. Obviously an architect should be technical but how much familiarity should they have with the technologies being implemented. I would say they should have a good understanding of them.

There is some benefit to being conceptually removed from low-level technology concerns, in that the architect won't get caught up in design patterns intrinsic in the technologies the devs want to use, that could actually be detrimental to the overall design - the old 'the devs can't see the wood for the trees' argument.

<comment><USER30> A technology architect should be technical and be able to keep himself on top of new developments in his area (software, networks, storage, etc) as well as having a good solid understanding of the adjacent or related areas. The focus is how newer and greater things fit together into the big picture.

A solutions architect looks over the fitness for purpose and is accountable for the delivery at project level which means that he might have to make decisions (together with his stakeholders) about which technology, framework or methodology to be employed in order to ensure the deliverables are mapped to the requirements with minimal or no slippage. The focus is business benefits from technology.

An enterprise architect is a whole different beast and I'm not even going to go there at this stage. I'll just say that being technical is as useful as being tall in that it makes for a good first impression but does not correlate to quality or effectiveness overall.

I am of the opinion that everyone involved in IT should have a good understanding of the past, present and future of technology as well as a systems thinking capability that allows one to understand how different systems interact and react to his own area of expertise. The balance of knowing how to do it and why do we do it is the difference between slave labor and expert work.

</comment></comment></comment></comment><comment><USER31> This might be controversial, but if you want a good example of a code base where this is painfully obvious look at Android, especially the UI components. There are interfaces for everyyyyything.

So many of the UI components are unnecessarily internal, which can be a pain in the butt if you want to do something just slightly different than default (you obviously can't inherit form an interface, so you end up copying the code). A lot of the cruft is probably from trying to make Java work, but when I read through the code I find myself wondering why it was implemented the way it was implemented and the only explanation I've been able to come up with is the one described in this post.

<comment><USER32> I completely agree. I find the Android APIs absolutely appalling.

My former coworker knows both iOS and Android, having done Android for many years, and he refuses to program for Android ever again. He would also tell me that the time it takes to implement things in Android is usually 1.5x - <USER2> longer than the equivalent thing on iOS</comment></comment>


I made this a while ago, but I don't know what to do with it? Ideas? - <AUTHOR> http://www.colorblynd.com <comment><AUTHOR> Well, compared to Bruce's Blowfish, it too is symmetric with a variable key length. What is different about ColorBlynd is that the block length can vary and the number of blocks within the key varies as well.

What this does is add a "meta key" beyond simply knowing the key. The meta key includes how the key is broken down into blocks. And the number of blocks is used during each round relative to the block length.

So if you know the exact key, but don't know how many blocks there are or how many bits per block, you wouldn't know that you had the entire key.

The whole color deal is a neat way to transport the key and the cipertext, but it isn't integral to the algorithm.

The actual algorithm can be succinctly described in 4 sentences.

I'd definitely like to have Bruce look at it, but I'm not sure how to convince him to check it out. If anybody here knows him personally and thinks this might be worth his time, please forward him this thread.

<comment><USER2> If I understand correctly, what you call the "meta key" is just a part of the key.

<comment><AUTHOR> Well, yes, the "meta" part is just how the actual key is broken down. What may be different is that decryption involves more than just figuring out the values for the key, but also its breakdown.

For example, if the bit length breakdown of each key chunk was 17, 15, 23, 12, 20, 19, 22 you would have a 128 bit key. But its not as "simple" as determining the 128 bits. There are 7 key chunks, and the length of each key chunk and the order of their bit length is essential to decryption.

The same key might be guessed with 6 chunks of different bit lengths. This won't decrypt it and in fact it won't even come close or give any indication that it was the correct key sequence.

So, this is what I mean by a "meta" key. There is an additional "dimension" to the key, this dimension means that there are an additional few magnitudes in the keyspace than simply the bit length.

So, in a simpler scenario, a 32 bit key, which normally would be pretty easy to crack, is much harder if you also have to determine if it breaks down: 5-13-9-5 or 17-15 or 9-32 or 5-7-3-6-11 or... The number of permutations are staggering.

Is there another cryptosystem that uses something similar?

</comment></comment></comment><comment><AUTHOR> I believe the basic algorithm is truly novel. The usage of colors is a little bit of a gimmick, but is an interesting way to store data.

I'm just not sure what I could use it for or if anyone might be interested in it.

One interesting aspect is that the algorithm is very dependent on the bit length of each chunk of the key as well as how many chunks there are. Almost like there is a meta-key.

Without this knowledge, even if you were to guess the entire key correctly, decryption fails without any indication that you were close.

As noted at the bottom of the page, I came up with the basic algorithm in 2002. I was researching several other cryptosystems and it was one of those "eureka" type moments.

So, any ideas, comments, criticism, or whatever is welcome.

<comment><USER3> I think there needs to be a bit more of a description of why it's different and better.

Run it by Bruce.</comment></comment>


Show Total User Karma in Hacker News Posts - <AUTHOR> https://kishanbagaria.com/userscripts/show-hn-karma/ <comment><USER2> I'm almost tempted to install this just to see how much it hinders the experience of using HN. User identity isn't something I look at before judging a comment, and total user karma has an even smaller correlation to value of any specific comment or submission. Anecdotally speaking, I have high user karma but I know most of my comments and submissions are pretty middlebrow. As another anecdote, on the front page is a very interesting submission about Mega Man on Temple OS [0], but the creator of that program only joined after seeing his work linked to from HN (i.e. he didn't submit it himself). And the most interesting comment I've seen today is from this user with <200 karma [1].

I typically only look at the _username_ when a commenter uses a personal pronoun and the submission involves a major company/organization/person; here's one in which karma score wouldn't have indicated as being particularly noteworthy [2]. It'd be kind of cool to see a plugin that used NLP to highlight these kinds of comments but I find that they are already "highlighted" by upvote count anyway.

[0] [https://news.ycombinator.com/item?id=13971627](https://news.ycombinator.com/item?id=13971627)

[1] [https://news.ycombinator.com/item?id=13966080](https://news.ycombinator.com/item?id=13966080)

[2] [https://news.ycombinator.com/item?id=8736450](https://news.ycombinator.com/item?id=8736450)

<comment><USER3> I have a hybrid approach. After having an unsatisfactory conversation or reading a comment I cannot agree at all, I quit but nevertheless look at that user's comment history to see why this happened. Occasionally, I realize who was wrong was I, or that user had a good reason to say so in spite of other arguments. I try to use the history only to learn more, so I ensure that I'm no longer a part of the discussion (that has failed anyway).

</comment></comment><comment><USER4> As a lurker, I tend to spend time on the few comments I write, rather than post my thoughts on every topic that needs further discussion.

Unfortunately, it's the latter behavior that nets more karma, more often than not. Those with high karma tend to be those who post or comment more, separating the frequent contributors from the lurkers.

If you intend to use this userscript, please do so knowing that the numbers you're looking at have little (if any) correlation with the quality of their corresponding comments. And reconsider. Thank you.

<comment><USER5> HN needs some sort of h-index

</comment></comment><comment><USER6> I find the idea that more information can actually hinder you to be pretty fascinating. This is not something I consider everyday. I wonder what other situation/ scenario would this be applicable to?

I also notice people getting upset over down votes once in a while. High karma users definitely command a certain respect.

All in all, I like how HN down votes comments from even high karma users if it's out of touch with the topic or is a meaningless vent. Hope that continues.

<comment><USER2> I believe information-filtering/overload to be the core challenge and driver of inspiration when it comes to how humans understand the world. The amount of information in the world (particularly, that we store and transmit) has increased exponentially, but our attention spans have not.

`More information != Better` is evident in contemporary web design, not just the seemingly retro-because-why-change aesthetic of HN (I say "seemingly" because I don't think HN's design motivation is out of curmudgeonly inertia). Look at the single-column experiences of Facebook and Medium versus what existed in the early 2000. Hell, look at the latest startup unicorn, Snap, in which information is mostly vertical photos and videos, and in which it is impossible to even review a history of past content.

The entire premise of data visualization is to simplify information. I'd argue that data, in general, is predicated of simplifying the world. Think of how many times you've read a survey or poll or study and thought that it was wrong because you, personally, aren't anything like those in your age group. Or, if you've ever applied to college or a job, how your GPA/SAT/ACT score, or previous salary, doesn't reflect the depth of your knowledge.

The benefits of reducing information seems to also be inherent in our current biological state. The vast majority of what the human eye can see, in terms of total _area_ , is relatively low resolution (i.e peripheral vision). The psychological tendency to rely on first impressions has been posited to have positive implications for survival. The perceived spottiness in human memory is also thought to be not just a physical limitation, but actual _feature_ : [http://articles.latimes.com/2011/may/29/opinion/la-oe-bar- me...](http://articles.latimes.com/2011/may/29/opinion/la-oe-bar- memory-20110529)

\----

On a sidenote, I'll admit to paying attention when I'm downvoted. But that's a reflection of how rarely I get downvoted and how little I downvote other people. And I think that in itself is a reflection of HN's moderation and decorum (don't use downvotes just because you disagree). OTOH, I don't get _angry_. When I get downvoted on HN. I have a general faith that it was because I screwed up -- e.g. I'm not as funny/witty as I think I am, or I was unnecessarily rude to someone else. And generally, that's the case and I've felt that that feedback has made me a more considerate writer over time.

<comment><USER7> _I have a general faith that it was because I screwed up -- e.g. I 'm not as funny/witty as I think I am, or I was unnecessarily rude to someone else._

Karma on HN and my fear of getting downvotes has had a chilling effect on my willingness to post humorous remarks.

This is probably a good thing.

</comment></comment></comment><comment><USER8> What I want is a way to flag comments, and threads on the homepage with comments, by users I have marked as interesting. This may be an okay proxy, but I have no idea how noisy it is since I normally don't see karma.

There's certain users that (often due to them being experts in a certain area) very often post interesting comments that I learn a lot from. I mainly find them by occasionally reading their comment history, but it would be nice to see them while the discussion is still ongoing.

A few examples: pcwalton, patio11, jblow, WalterBright

<comment><USER9> Something like this? You could just package this as an extension or something.

var likedUsers = ['pcwalton', 'patio11', 'jblow', 'WalterBright'];

var users = document.getElementsByClassName("hnuser");

for (var i = 0; i < users.length; i++) {

        if (likedUsers.indexOf(users[i].innerHTML) != -1) {

              users[i].setAttribute("style", "font-weight: bold;"); //Or whatever

        }

    }

<comment><USER10> Wait, not like this?

      document.documentElement.innerHTML =
        document.documentElement.innerHTML.replace(
          new RegExp('(?:' + ['pcwalton', 'patio11', 'jblow', 'WalterBright'].join('|') + ')', 'g'),
          '<B>$&</B>'
        );

DHTML!

<comment><USER9> Because regex is costly. Your solution takes 27.1 ms on my machine, and my script takes 12.4 ms.

<comment><USER10> (It's a joke, with poor delivery it seems. It also pointlessly replaces things in <head>. Also, it clobbers every element on the page, attached event handlers included, so it's expensive _and_ destructive. To be clear, it's expensive because it treats the page as a string rather than using the DOM and replaces every element, not because regular expressions are expensive, which they aren't. As far as string replacements go, it's pretty quick. The underlying joke is it's a 1997 JS novice/Perl monk's attempt at replacing your O(n*m) script, which really needs no optimization, hence the dated <B> and "DHTML!"... I'll see myself out).

</comment></comment></comment></comment></comment><comment><USER11> Although others object to karma displayed prominently next to a username, I'm wouldn't be against it --if-- the karma was more meaningful.

The problem is that karma score _combines_ points for submissions _and_ comments. Those are very different activities to combine into a single mathematical scale. (Yes, I know that's also how other sites like Reddit works and a single score is "simple".)

Upvotes for _submissions_ is saying something about the userid's curation and/or the type of topic. Some topics are "hot button" and attract upvotes even though the actual writing within the article/blog is substandard.

Upvotes for _comments_ is saying something about userid's generative mind. His/her brain has an opinion and the fingers type it out.

As an analogy, karma combines upvotes for how a disc-jockey selects (curates) music with the upvotes for how a musician performs live music. This doesn't invalidate the DJ's effort but combining the scores means we lose more information than we gain.

I suppose the higher level abstraction we can use to justify a "composite" score of 2 very different activities is the concept of "participation score". In that way, karma==participation. In that case, does showing a participation# add useful information to the posts?

<comment><USER12> Not to mention that submission karma is way easier to acquire. Around a third of my karma is from one submission, for instance.

</comment></comment><comment><USER13> If you want to determine the value of a user's comment by the community's knee-jerk reaction to said comment, go back to reddit.

<comment><USER14> It's showing overall user karma, not individual comment karma, so it's still far from reddit. Not so sure it's a good thing, all the same.

</comment></comment><comment><USER15> Although I believe it is a great add-on to have, I believe it would create bias.

</comment><comment><USER16> Excellent. All that time grinding a few comment karma for each small, trivial, mediocre quality post will finally add up to the respect I deserve.

<comment><USER17> This is a good post. I hope this was a good comment.

</comment></comment><comment><USER18> the relevant part of the code:

        function getKarma(userName) {
            get('https://hacker-news.firebaseio.com/v0/user/' + userName + '/karma.json', function(karma) {
                appendKarma(userName, karma);
            });
        }

</comment><comment><USER19> This is a bad idea.

Put a metric and even self aware people get influenced by it.

</comment><comment><AUTHOR> Ah, a bit of confusion with the title -- It's literally "Show HN Karma," not a Show HN.

I've updated the title to clarify, but if a mod can think of a better version, feel free.

<comment><USER20> "Show user's total karma" would also be a helpful bit of info, since the assumption (a la reddit) would be "karma for that particular post"

</comment></comment><comment><USER21> I took the opposite direction. I have a small chrome extension to remove all mentions of karma on HN.

I had the same issue on Reddit and with the Github streak counter. My brain stays focus on the number, even if I don't want to.

</comment><comment><USER22> Isn't this a feature HN had before and intentionally removed?

<comment><USER23> Yes. Comment scores, user points and average per comment.

The last was the most useful.

<comment><USER2> FWIW, the reasoning for removing the average karma per comment metric, which was about 2 years ago:

[https://news.ycombinator.com/item?id=8264220](https://news.ycombinator.com/item?id=8264220)

> _It 's based on comment scores only. My sense is that it's an irrelevant > distraction and we should get rid of it. For example, we caught a bunch of > users who were gaming it by deleting any comments that brought their average > down. We fixed that by treating deleted comments as comments of score 0 for > average-computing purposes. It's an example of how, once you publish a > metric, people start to care about it and do things based on it, regardless > of how meaningful it is. Comment average used to be used by a few algorithms > (like comment ranking) but we turned that off as an experiment a while ago > and nothing seemed to get worse. If anything, I think it may have helped a > little._

</comment></comment></comment><comment><USER24> What I'd like is a way to hide the user globally while still tracking locally. By that I mean not knowing who a commenter is across other pages but knowing they're the same person replying back to you.

Something like HMAC(username, story_id) would work for this. It's be consistent on a given page, but not immediately apparent so people would either judge comments more on their quality or simply click the user more to see who it is. I'm curious to see which it'd be.

</comment><comment><USER25> Note for the author if they're reading - Tampermonkey has a Safari release as well, and the script works as expected in Safari.

</comment><comment><USER26> I'm not a fan of this. I like HN because we're all shown equally (unless you actively click on a profile link that is).

The only thing I'd like, as others have said is my own ability to highlight the names of users I think are interesting (to me) - much in the same way new users are green, maybe have my own personal list of users who are in, say, red.

</comment><comment><USER27> It would be good to have a direct link to the source.

<comment><USER28> [https://gist.github.com/KishanBagaria/58617aa6f7bcb5c96dfd/](https://gist.github.com/KishanBagaria/58617aa6f7bcb5c96dfd/)</comment></comment>


The Challenge of Millennial Workflow - <AUTHOR> https://medium.com/hop-email/the-challenge-of-millennial-workflow-c3df58c1672d <comment><USER2> TL,DR: millenials have ADD, don't like to do boring things and need to feel special in their jobs.

Also, article is just an ad for their email application.</comment>


An Intellij, Android Studio Plugin to Set Up GraphQl to Android Project - <AUTHOR> https://github.com/jumaallan/ZealPlugin <comment><AUTHOR> This is a simple Android Studio and Intellij plugin that allows easy setup of GraphQL in your Android App with little or no knowledge of the same.

Just enter your GraphQL endpoint url, and hit ok. GraphZeal will generate the packages and schema.

Do share how using this goes ;)</comment>


Warren Buffet's Alpha [pdf] - <AUTHOR> http://docs.lhpedersen.com/BuffettsAlpha.pdf <comment><USER2> I don't disagree with the conclusion that but there more stuff hidden into 'cheap stocks' than is explained in the paper.

Berkshire receives substantial advantage from the structure it's business and I'm sure it's not an accident.

Bershire is basically insurance and re-insurance operation that uses its steady income and substantial float to finance investing business. It shortcuts banks and external financing and the markup they take.

Compare BRK.A to SP500TR (SP 500 Total return is good comparison because BRK is not giving dividends). BRK matches SP500 when everybody has access to the cheap money. But when downturn or market crash hits and the money is tight BRK starts to shine.

TL;DR: buying cheap stocks is easier when you have constant access to cheap money during those times when others don't.</comment>


Magnus Carlsen and Fabiano Caruana play to thrilling Game 10 draw - <AUTHOR> https://www.theguardian.com/sport/live/2018/nov/22/magnus-carlsen-v-fabiano-caruana-world-chess-championship-game-10-live <comment><USER2> What I'm finding thrilling is having (since Game 9) Anish Giri, Alexander Grischuk and Peter Svidler commentating together on chess24, and streaming live on youtube. I don't think there's ever been a commentary team nearly so strong - current world #5, #9 and #19. And it's free. Thank you internet!

[https://www.youtube.com/user/chess24media/videos#top](https://www.youtube.com/user/chess24media/videos#top)

<comment><AUTHOR> Thanks! I have been looking for a reliable source, I'll check this out.

<comment><USER2> :-) Well.. here's some more links. I visit all these regularly.

For chess news:

Chess24 news [https://chess24.com/en/read/news](https://chess24.com/en/read/news)

ChessBase news [https://en.chessbase.com/](https://en.chessbase.com/)

Chess.com news [http://www.chess.com/news](http://www.chess.com/news)

The Chess Mind blog [http://www.thechessmind.net/](http://www.thechessmind.net/)

Videos/Live commentary:

St Louis Chess Club [https://www.youtube.com/user/STLChessClub/videos#top](https://www.youtube.com/user/STLChessClub/videos#top)

Ben Finegold: [https://www.youtube.com/channel/UC6EnFbK-P5q0zeaqI5yobKg/vid...](https://www.youtube.com/channel/UC6EnFbK-P5q0zeaqI5yobKg/videos#top) and [https://www.youtube.com/channel/UCqLLqbclDQ6IQg39Wsgy-4w/vid...](https://www.youtube.com/channel/UCqLLqbclDQ6IQg39Wsgy-4w/videos#top)

GingerGM [https://www.youtube.com/channel/UClV9nqHHcsrm2krkFDPPr-g/vid...](https://www.youtube.com/channel/UClV9nqHHcsrm2krkFDPPr-g/videos#top)

Daniel King's PowerPlay Chess [https://www.youtube.com/user/PowerPlayChess/videos#top](https://www.youtube.com/user/PowerPlayChess/videos#top)

John Bartholomew [https://www.youtube.com/channel/UC6hOVYvNn79Sl1Fc1vx2mYA/vid...](https://www.youtube.com/channel/UC6hOVYvNn79Sl1Fc1vx2mYA/videos#top)

Chess.com [https://www.youtube.com/user/wwwChesscom/videos#top](https://www.youtube.com/user/wwwChesscom/videos#top)

In spanish:

Chess24 [https://www.youtube.com/channel/UCTzRQxC3i7GOT4jtiTq4e0w/vid...](https://www.youtube.com/channel/UCTzRQxC3i7GOT4jtiTq4e0w/videos#top)

Chess.com [https://www.youtube.com/channel/UC3Pi- wg_YPjnd3RSEDQ2V8w/vid...](https://www.youtube.com/channel/UC3Pi- wg_YPjnd3RSEDQ2V8w/videos#top)</comment></comment></comment>


Running Kubernetes Example on CoreOS, Part 2 - <AUTHOR> http://coreos.com/blog/running-kubernetes-example-on-CoreOS-part-2/ <comment><AUTHOR> Hi thanks for another great post.

I've started with similar project running mesos-marathon on top of CoreOS. ([https://github.com/veverjak/coreos-mesos- marathon](https://github.com/veverjak/coreos-mesos-marathon))

I was wondering whether kubernetes has same resource management like mesos - meaning can I get info about minion usage.</comment>


Ask HN: Why no O'Reilly Golang book? - <AUTHOR>

O'Reilly has an extended list of "early adopter" titles, and always had strong support for new and emerging languages back in the day. Any reason it seems to avoid Golang? <comment><USER2> The real question is why doesn't Kernighan and Pike have a book on the subject. Even better Kernighan and Thompson; better yet all three K&T&P.

</comment><comment><USER3> The documentation on the golang.org site is pretty good. Besides, the revenue from books is dropping rapidly. There is little incentive to write a book - which is a massive effort, for a paltry sum.

<comment><USER4> Paltry sum for book publishers, maybe.

It's too easy to self publish these days. Several HN posters have written there own books in a relatively short period of time and made >25-50k, which is probably better than their hourly rate.

If somebody like Dave Cheney or Gustavo Niemeyer wrote and self published a go ebook, I'd certainly buy it.

</comment></comment><comment><USER5> Who do you think should write this book?</comment>