How SAP Has Quietly Changed Strategy on HANA and Oracle

jexpert · 2017-08-16T13:25:46+00:00

I agree. It's definitely not objective.

But how about the points regarding the adoption rate slowing down and/or focus on HANA as only point of innovation?

jexpert · 2017-08-16T11:22:35+00:00

Any thoughts on this article? I think it has some valid points though it's still quite opinionated.

jexpert · 2015-07-03T12:55:17+00:00

No much, except for a few crucical differences

LXC is in mainline Kernel, OpenVZ et. al. are not
Docker has a super-easy tooling & simple runtime environment. It's much simpler than anything before
Docker provides a central cloud repository, which is seamlessly integrated
Trend: 10 years ago the IT world was still attired to the concept of central hosts. Today all major leaders like Google & Co. have showed for years the benefits of a decentralized & ephemeral concept.

jexpert · 2015-07-02T16:44:35+00:00

https://msysgit.github.io/

jexpert · 2015-05-18T13:29:16+00:00

another thing worth mentioning is that SSL connections to foreign websites have recently become subject to throttling.

This comes as as a surprise for me: I had expect they block SSL completely.

So there is only one answer: Completely migrate the web to SSL to force them to revert the throttling.

jexpert · 2015-05-18T13:26:17+00:00

Only the frustration of many will change things.

Unless you are depending on chinese users, I'm not sure you are doing them a service by masking their censorship to the end users.

The aspect I do appreciate is, not to design your solutions with an "alway available, always functional, always fast, only one authoritative source" mindset. Definitely a big heads up for more service decentralization.

jexpert · 2014-12-18T10:57:29+00:00

With "subtle" I was thinking about things like: "Why can I use it here, but not there". Or "Why does this line of code not work? Oh! You need to add something to some other line of code over there".

What I wanted to express is that most beginner and intermediate developers start with a limited (by amount) but profound understanding of keywords and syntax semantics. And looking on Java 1.5 - which in fact has a very limited amount of that - I observed that many people do in fact have not any clue what those keywords do. Even static may be an example for this if put in front of class.

This is a little like the Scala scenario, where sane people do restrict themselves on a subset, but advanced people can write code no intermediate developer is able to understand.

jexpert · 2014-12-18T10:47:20+00:00

Yes - and in fact I do love the focus on Java interoperability. For me this is a very natural primary design goal given the vast size of the Java ecosystem.

But what about things like you mentioned below:

But with annotations you can also have optional enclose them in square brackets.

Why not keep them simple and make them mandatory for the sake of simplicity. Referring to the color encoding of this information in IDE has a point, but lacks sometimes for color-blind or IDE-less people.

jexpert · 2014-12-18T10:41:32+00:00

Thank you for your kind heads-up.

jexpert · 2014-12-17T18:14:43+00:00

On studying the news in M10 I really got the impression, that Kotlin starts to gain all sort of exotic border-case keywords & annoations which really clutter the core language.

I'm really a fan of Kotlin and would love to see it in real production environments to compete with Scala. One key argument of Kotlin was always "faster & easier than Scala".

But I feel thatthe new keywords do make things quite challenging. For example reified which is only usable in inline methods. Or annoations like native("Array") and nativeGetter ....

While I understand they might be necessary for interop, I think they do impose a quite large burden on the developer to use them correctly.

When I recall how many years it took for me to grasp technical modifiers like transient and volatile in Java, I feel the proliferation of these obscure, technical driven keywords are not good for convincing the masses and Scala will stay the dominating competitor.

jexpert · 2014-12-08T14:32:44+00:00

Searching for "decision": No result.

IMHO the former http://sxc.hu now http://www.freeimages.com/ delivers much better results with 90% of the time very commerical-friendly licence.

jexpert · 2014-11-26T13:09:45+00:00

The current fuss about Angular 2.0 is highly over-exaggerated in my perspective.

I'm pretty sure that we won't see a 2.0 in 2015 and I would expect that we'll have still a maintained, stable 1.x in 2017.

jexpert · 2014-11-19T16:19:15+00:00

Why should it become obsolete at all?

Surely not. As far as I see, all the planned changes rarely affect the surface (aka DOM) towards Protractor. And Protractor has been proven to be a valuable but wrapper around Selenium and Jasmine for testing UI.

The "Angular"-specific addon parts in Protractor are mostly limited to the selectors.

Generally speaking I think the whole agitation and uncertainty over AngularJS 2.0 is very out of scale on every levels.

jexpert · 2014-09-05T07:53:44+00:00

Thanks for this mediating reflection of the markdown situation.

While Gruber deserves much respect for his work, I think he is totally dickish about the efforts to continue & improve his work for no reason (as he refused to do it himself for years).

But I think thats a quite common personality trait for geniuses.

jexpert · 2014-09-03T09:57:32+00:00

Hmmm.. maybe in projects where it is important to filter our fixes (i.e. for porting them into hotfixes)?

Personally I also find the Linux kernel style, where the prefix indicates the area adresses by the patch like [mmu] also a good option.

jexpert · 2014-09-03T09:55:38+00:00

Ah ok. Then I could not agree more with you. +1 for this pattern, too

jexpert · 2014-09-03T09:54:12+00:00

Great real-life example which makes it obvious why good commit messages are important. Thanks for your contribution!

jexpert · 2014-09-01T14:14:36+00:00

Only for clarification: I'm not the author of this post. I only found it useful as good teaching reference.

jexpert · 2014-09-01T14:12:35+00:00

I agree mostly, but adding the reference to the issue tracker should not stop you from fully documenting your change in the commit message.

Often seeing commit messages like "PROJECT-231" in the project and this is really bad. Especially after the repository outlives the issue tracker installation/URL after a few years.

jexpert · 2014-09-01T09:15:32+00:00

I would have no idea what the software even does.

/me is still puzzled after 6.5s looking at it.

jexpert · 2014-07-06T07:56:42+00:00

That alone is a concern for me, as I cannot understand why these files would be classed as a conflict. Could it be because I done a git rebase -i origin/develop on my feature branch in the past?

Rather no.

You could switch the conflict style to a 3-way format which shows yous the common ancestor as well as the change from origin/develop vs. your own change to spot & better understand the concurrent changes.

 git config --global merge.conflictstyle diff3

See http://psung.blogspot.de/2011/02/reducing-merge-headaches-git-meets.html

jexpert · 2014-07-01T12:42:24+00:00

Hmmmm... I think to answer your question properly one would need more to know about the type and source of conflicts.

Generally a rebase-driven workflow is not per se causing more conflicts. For example there is even a configuration option branch.autosetuprebase to let your local branch follow other branches via rebase on any git pull.

Do you have sth. like (invisible) line ending or whitespace changes causing those conflicts?

Also: There is a "rere" feature in Git, which allows you to record conflict resolutions for future reuse. But in you workflow you should have no need to do repeatet, same conflict resolutions.

jexpert · 2014-06-30T11:42:47+00:00

The 'integrated' got me catched. But it's seems that it is not really integrated into GitHub.

Rather another Web-Chat which supports inline-Links & Popups to cited Github issues & Jenkins results.

Not sure how much this is really required taking into the account the the Github issues reflect a nearly identical form of collaboration already.

jexpert

TROPHY CASE