Comments for Mimozar Blog

Comment on Apolitical tech community, what a load of non-sense! by Indranil Bhattacharya

Indranil Bhattacharya — Thu, 18 Jun 2020 06:43:19 +0000

A slightly more difficult topic, but perhaps equally if not more worthwhile discussing, is the role of tech communities and platforms in propagating and reinforcing a social or political status quo, whether in terms of race, gender, financial wealth, or disability. Tech communities and platforms should exist to serve societies, whether people in a building using a CRM/ERP application or people outside the building using a public service. But more often than not, they tend to serve market speculation, clique conformity, and reinforcing status quo positions.

Comment on Code frameworks and ghettos, where creativity gets a lock-in by Interesting thoughts: Frameworks are fundamentally broken – Mimozar Blog

Interesting thoughts: Frameworks are fundamentally broken – Mimozar Blog — Sun, 13 Nov 2016 15:56:00 +0000

[…] Tim’s article calls for reflexion. My own take on the issue was triggered as I spotted a rant on Rails (of Ruby on Rails). My post is Code frameworks and ghettos, where creativity gets a lock-in […]

Comment on Pimping my MacBook Pro late 2008 – Part 2, installing a SSD as second disk and boot drive by FORMULA ONE FURNICHE

FORMULA ONE FURNICHE — Wed, 26 Oct 2016 18:48:08 +0000

I truly appreciate this article post.Really thank you!

Comment on Four days with my Upgraded MBP to MacOs Sierra, a few minor tweaks, but so far no complaints. by Isaka

Isaka — Fri, 14 Oct 2016 12:04:53 +0000

In reply to vicaba. Yes, they are system variables although they are not present by default. Someone has to have manually added them. If you are not developing with Scala then you can safely ignore SBT_OPTS. Likewise, if you are not developing in Java then you are not likely to need JAVA_OPTS. But I am assuming you do, and therefore you would be ok with starting up Terminal.app, using your favourite text editor (VI, Nano, or other), open .bash_profile (the system defaults is BASH), and either add or change these variables. If you don't find these on your machine then you probably never needed them until now and thus can safely ignore them.

Comment on Four days with my Upgraded MBP to MacOs Sierra, a few minor tweaks, but so far no complaints. by vicaba

vicaba — Mon, 03 Oct 2016 15:46:47 +0000

Hi,

Where Can I find the “JAVA_OPTS” and “SBT_OPS” variables? Are they system variables?

Thanks,

Comment on Eclipse Che looks promising, the cheese’s moved around by Eclipse Che | Blog

Eclipse Che | Blog — Fri, 27 May 2016 20:16:16 +0000

[…] March 12, 2016: A very quick look at Eclipse Che shows a promising concept… Read More […]

Comment on Eclipse Che looks promising, the cheese’s moved around by Isaka

Isaka — Sun, 13 Mar 2016 09:02:04 +0000

In reply to Tyler Jewell. Interesting. I need to dive into the details. As the IDE becomes distributed, it also inherits the challenges inherent with that architecture. I'm curious how this is being addressed, so I've got to look at the source code. Rewriting the UI is going to give plugin developers quite a bit migration work to do. Most of the IDE reinvention endeavours I am aware of have really just focused on replicating the Eclipse model around a text editor, not much reinvention in my view. The ones that took the playground approach, like Xcode, have offered more. Che's a hybrid WorkStation/Server model is innovative from the deployment perspective, but I think it could be ambitious beyond Docker though. The IDE of 2016 could benefit by being a streaming hub for a network of components, would you see Che going in that direction or would you rather it only focuses on the microservice idea and not much else?

Comment on Eclipse Che looks promising, the cheese’s moved around by Tyler Jewell

Tyler Jewell — Sat, 12 Mar 2016 20:57:40 +0000

Che has its own type of plugin system that is similar to that of the Eclipse RCP, but notedly different. In Che, the workspaces are distributed, so there are three types of extensions: those that run within the IDE, those that run within the Che server, and those that run within the workspace (which has its own runtime). Workspace extensions are essentially RESTful APIs that are deployed that can do magical things in the workspace & projects. IDE extensions modify the browser behavior, and can connect back to the extensions that are RESTfully exposed from within the workspace.

Eclipse extensions can move over – but it’s easiest to move the server and data logic extensions into the workspace. Eclipse GUI extensions have to be rewritten from SWT into GWT, which is what we used to generate the JavaScript IDE.

Comment on Eclipse Che looks promising, the cheese’s moved around by Isaka

Isaka — Sat, 12 Mar 2016 18:40:35 +0000

In reply to Tyler Jewell.

That was a super fast reaction! Thanks for taking the time to clarify. You and team clearly are on he ball.

I certainly am not underestimating the challenge of reinventing a platform that’s been so successful. The containerisation pattern is definitely promising. I did wonder about potential fragmentation. For example, whether the plugin system would be moving in that direction too. If not, wouldn’t that keep some complexity around? And if it did, then the granularity (as opposed to OSGI or Project Jigsaw) could also come to question.

This is such an undertaking that I also want to take the time to applaud the achievement so far.

Comment on Eclipse Che looks promising, the cheese’s moved around by Tyler Jewell

Tyler Jewell — Sat, 12 Mar 2016 17:55:22 +0000

Hi – I am the project lead for Eclipse Che. You wondered why Docker was being used. The simple idea behind Che is that the workspace needs to include all of its dependencies so that if you wanted, a developer could move the workspace around from one location to another and then pick up development where you left off. The runtime in this case is the tools like compilers. So Che workspaces have embedded environments. Our default environment implementation is Docker containers, but you could implement this with MacMini or zOS for instance.

Unfortunately, Docker requires a VM on Mac and Windows, but this is a temporary issue.