No ha donat temps de provar els avantatges del Java SE 9 que Oracle ja ha llençat la nova Java Standard Edition 10. Això junt amb les noves característiques del servidor d'aplicacions, complint amb l'especificació Servlet 4.0 de la darrera versió Java Enterprise Edition 8. Emocionant tot plegat.
El servei BaaS s'actualitzarà en breu amb aquestes darreres versions. Ja es va preparar aquest Nadal passat, quan s'actualitzaren totes les llibreries del servei, i serà una realitat aquest mes de maig a tots els serveis BaaS.
De tots els avantatges propis de la màquina virtual, destacant potser el Parallel Full Garbage Collector. De les millores en el codi compilat, operacions concurrents i execucions en paral·lel.
Però potser la part més vistosa són les millores en les keystores per a certificats digitals i l'encriptació TLS. Aquestes es propaguen fins el servidor d'aplicacions, permetent allotjar certificats en serveis BaaS compartits. Mai haurà estat tan fàcil tenir un domini segur amb https
.
Res. El servei s'actualitzarà un cop hagi passat la fase beta en producció. Els clouds s'actualitzaran i es re-iniciaran en horaris nocturns i en cap de setmana.
Si tens algun dubte respecte l'actualització o els certificats digitals pel teu domini, contacta suport@turro.org.
Next release of the Elephant libraries will come with formatting support for social networks. The goal is achieved by generating Open Graph metas.
Images can be socialized by simply following the instructions in http://www.turro.org/docs/elephant/components/social. For publications, images will be selected using the conventions described in http://www.turro.org/docs/brightside/publications/conventions.
Twitter example
Whatsapp example
Facebook example
Google Drive per a Mac/PC es desactiva definitivament el 12 de maig de 2018. Tots els usuaris que el facin servir com eina de sincronització hauran de migrar a File Stream de Drive.
File Stream de Drive és una nova aplicació per a Mac o PC que et permet accedir a tots els teus arxius de Google Drive des de l'ordinador al mateix temps que s'estalvia espai en disc i es redueix el temps de sincronització.
Amb File Stream de Drive pots:
Visita el Centre d'Ajuda de Drive per instal·lar File Stream de Drive i començar a utilitzar aquesta aplicació.
The new Elephant version comes with some new features that will make life easier for SEO. The most relevant are:
Previous to Elephant URL-as-parameter, BrightSide Publication URLs were generated using the publication ID. Something like ?item=n
. This has been override by easy-to-read URLs. Something like /elephants-new-features-for-seo
, which happens to be the URL for this one you're now reading.
Currently, the URLs are auto-generated when the publication is saved. And wont change in future savings. The new system is backward compatible with the previous one.
The URL-as-parameter generates when publication entities have their own context defined. See Sitemap.
The links affected (but not exclusively) are:
Elephant generates a sitemap from all its contexts. Also, requires BrightSide modules to provide relevant URLs. See Sitemap for more information.
Before start, I would like to mention Apache Tika and juniversalchardet. Tika is a full-featured file type detection library and, because so much features, takes a big amount of dependencies. I haven't tried juniversalchardet for does not detect ISO-8859-1
, which is the reason I needed charset detection.
Since none well suited my problem, I decided to detect charsets myself and, once results were in production, share it with anyone else. Hope you like it
Anyone developing web applications with data inputs and third-party frameworks, with a different charset than UTF-8
, might have encountered the need to auto-detect charset. Guessing the source of the input on utility classes, or passing the charset along among methods, doesn't seem to be the right way and isn't always possible.
We'll need a convert method, in order to change the string charset. The most simple way would be using String
supplied methods. Something like:
public String convert(String value, String fromEncoding, String toEncoding) { return new String(value.getBytes(fromEncoding), toEncoding); }
The problem remains, though. The variable fromEncoding
isn't always known.
Guessing? Well, let's be clear, we are guessing. Also taking some premises that might be not true. For instance, we probe using UTF-8
against a set of expected charsets. The good thing about it is that we know the elements at play and can change them at will.
The approach is very simple: if I do change the string from the expected charset to UTF-8
and then back from UTF-8
to the expected charset, shouldn't be the resulting string exactly the same than the original one?
Let's put this at work:
public static String charset(String value, String charsets[]) { String probe = StandardCharsets.UTF_8.name(); for(String c : charsets) { Charset charset = Charset.forName(c); if(charset != null) { if(value.equals(convert(convert(value, charset.name(), probe), probe, charset.name()))) { return c; } } } return StandardCharsets.UTF_8.name(); }
A possible call to the charset()
method would be:
String detectedCharset = charset(value, new String[] { "ISO-8859-1", "UTF-8" });
As I said, the approach uses the premise that UTF-8
will behave well on all transformations and that there is a reduced set of expected charsets. I haven't tried probing the whole Charset.availableCharsets()
. In case you do and find a better way, please let me know.