syjer

I think it's this one: https://news.ycombinator.com/item?id=35114009

From my experience, enterprise apps are generally complex because they are a combination of:

- environment: integration of a large amount of services - and a good amount of them are legacy and idiosyncratic

- use case: enterprise app are at the intersection of real life and the virtual world: the rules are messy, illogical and have a baggage of 20/30+ years. Thus they cannot be changed at all. This is IMO the main difference between a "pure" greenfield startup kind of project and the enterprise one.

- add another layer of burocracy and complex environment to navigate

And with that you got the enterprise app world :).

In the end whatever framework is chosen, the most important property is the availability of common language/patterns.

You may notice that in the linked article, only the artifact id has been spoofed. In maven you need to declare both groupId and artifactId for your dependency (and a fixed version, a range is generally considered a bad practice).

To be noted, it makes this kind of attack more difficult, but not impossibile.

Especially the mix public/private artifacts. I guess it will force a lot of companies to at least lock their groupId on maven central, if they never bothered to do so.

The trick is setting the right redirect_uri [0].

Generally it's implemented with a custom URI scheme (that the target application is registered for) or a loopback ip address.

[0] https://developers.google.com/identity/protocols/oauth2/nati...

Yes you can upload: https://support.google.com/youtubemusic/answer/9716522?hl=en .

The UI/UX of youtube music is lacking compared to GPM, but at least the file locker functionality that I use is still here.

And create an accessibility nightmare.

Hi, one of the devs here. I would like to clarify that this project has been developed as a side-project, it's not (at least, during that timeframe) our main work.

So don't take the time to develop a feature as a 100% full time work :)

Hi,

You are right about angular. We already have done 50% of the work, as we have the "customer" facing part done in angular 8 (https://github.com/alfio-event/alf.io-public-frontend).

In the next release (M3) we will convert the "admin" part too (we are targeting a new frontend built with angular material) :)

If you consider that window, normally use third party drivers (by amd, intel, nvidia) which bundle by default vulkan.

Linux distributions and the more recent android versions?

>The absence of a package manager like Bundler or Cargo was frustrating

why you did not use maven or gradle?

I think that the approach done in https://wiki.openjdk.java.net/display/loom/Main is better than the async/await infrastructure.

There is a subset with spring-fu (https://github.com/spring-projects/spring-fu). They are working to support the native-image feature of graalvm (https://github.com/spring-projects/spring-fu/issues/29).

our little project support ldap for the login part: http://lavagna.io/ .

Oracle Java is based on OpenJDK and certified by Oracle. So I don't see how pouring vast resources into OpenJDK would make "Oracle Java" obsolete.

1.7: as java.util.Objects is present ( https://android.googlesource.com/platform/libcore.git/+/mast... )

This style is quite prone to escaping/sanitization issues. I would have at least used a template engine instead of concatenating strings.

They sold a lot of shares during the alibaba IPO in 2014 : https://investor.yahoo.net/secfiling.cfm?filingid=1193125-14... .

Clear, but the single rt.jar will be replaced with a more convenient representation, so, as you said, the seek time will be reduced.

That's why it's called a modular jar. There is also this "jmod" file described as:

"For the purpose of modularizing the Java SE Platform’s reference implementation, the JDK, we will introduce a new artifact format that goes beyond JAR files to accommodate native code, configuration files, and other kinds of data that do not fit naturally, if at all, into JAR files. This format leverages another advantage of expressing module declarations in source files and compiling them into class files, namely that class files are independent of any particular artifact format. Whether this new format, provisionally named “JMOD,” should be standardized is an open question."

Edit: from http://mreinhold.org/blog/jigsaw-modular-images

"The internal files rt.jar, tools.jar, and dt.jar have been removed. The content of these files is now stored in a more efficient format in implementation-private files in the lib directory."

>Except they don't mention at all how a module system should lead to faster boot times.

They will switch from the basic jar (zip) format to a more optimized one. Additionally, with a modularized jre, it will load less modules (who use corba?). I'm quite sure there are additional reasons, but it's the 2 that I remember.

For the i18n, the basic pieces are already there. I'll provide a guide on how/what is needed to translate the application.

(Probably there are some issues in the gui for RTL languages and for CJK in the full text search support)

I've answered in the github issue https://github.com/digitalfondue/lavagna/issues/10 :)

Thank you, kinda sad that Persona didn't get traction :(

Thank you for understanding the choice of the language :).

In fact we (3 of us) are all working in a "big" enterprise settings so we kinda know (and suffer sometimes) about the general constraints of deploying external software (it's more probable that a java or dotNet app will be accepted than something built with an exotic stack that require others additional software that nobody is able to operate internally).

Anyway, for running lavagna you don't need a big server, I'm running it on a small (free) 512mb of ram server from openshift _with_ a mysql instance in it! This is a 5usd/month instance at digitalocean.

>What's your business model with Lavagna?

We are developing it in our spare time (I don't work full time so I can do projects like that), so nothing concrete at the moment, we are open for any opportunity.

I've considered Go, but it does not really fit my criteria:

- lack of generics (sorry, but even though I kinda like go as a language there are features that I consider mandatory)

- lack of decent dependency handling (I don't consider vendoring a good solution, with maven central I know that the libraries will be there forever and there is a versioning scheme, pointing to the master branch of a git repo is not a good solution either, I value stability)

- lack of officially supported sql drivers and libraries like lucene (sorry but I don't really want to depend on a random github repo, it does not give me enough ensurance that it will be mantained)

(And I don't think that a statically linked binary/smaller binary/less memory footprint is a good enough reason to dump the jvm and his ecosystem)

Thanks for the feedback.

I admit that I still don't understand why java receive so much hate.

What kind of language would you prefer for a server side application and why?

For this project I've chosen java _because_ it's a boring language, I really don't want to be enabled to write clever code that will be unreadable after few months.

Additionally, with a jvm I've got extremely good libs/tools for developing the application, and when in production a whole heap of monitoring tools.

So uh, sorry for liking the jvm :(.

(And it's not that I know only java, far from it...)

edit: and still, I don't think that requiring a jvm runtime is asking too much. I mean, if you use a managed language, you will need a runtime.

That's why I packaged the application in two way:

- a .war for deploying in a standard 3.0 servlet container

- a self contained executable war that has a embedded jetty http server

For the self contained option, you only need a working java 7 runtime. I don't think that I can do it simpler than that.

Additionally, if you prefer an even more automated way of updating the software, the application is available on maven central, so you could (as we are currently doing it in our openshift instance) use the maven jetty plugin and select the depedency.

I can't really think of a simpler deploy system. (except statically linked binary, obviously, but there you need to select the correct os :))

edit: we have a docker image for testing purpose too.

We are dogfooding the program on a small (free) openshift gear which provide only 512 mb of ram (and we have in the same "gear" a mysql instance).

It does not use _that_ much of ram. (And yes, it has a basic trello import functionality).

It use a little bit more of memory than a php application for sure, but it work on a small openshift free "gear" as we are dogfooding there (which is 512mb of ram: https://www.openshift.com/products/pricing) with everything crammed in: jetty + mysql on a single node.

You can follow the guide for openshift here: http://lavagna.io/help/openshift/ .

I'll see if the free heroku tier work decently and provide a guide too.

(And yes, it will work on a 5usd digitalocean instance, as it's strictly more powerfull than the free gear from openshift)

Not wanting to start a language war, but targeting the jvm give me a good level of confidence that it will work everywhere due to his good backward compatibility.