If you worked with or heard about REST then you might also come across GraphQL. It's a technology initially developed at Facebook.
In GraphQL, the shape of the response is built up on the server side to match the shape of a given JSON query.
So while in REST when you ask for a "book" item you receive a predefined JSON response with all attributes of the book. In GraphQL you might ask only for the books title or in another case for the books title and author at the same URL and receive an appropriate response.
Given that the mailing lists are often used to ask questions when we get in trouble, report bugs and other issues, conduct public discussion between strong headed individuals, we quickly forget what a fantastic platform Pharo is.
Last month I implemented a rough MVP-style ticket sales platform that was successfully used to sell and validate at the entrance, about 1000 digital, online tickets for a relatively large 3000+ attendance event (a party). It took only a couple of days to build and deploy, and it was a lot of fun – it was even done in ‘unstable’ Pharo 7.
Early on I decided to identify each individual ticket by a unique URL. For easier presentation and scanning purposes, I encoded that URL in a QR code.
Although I am grateful for the whole Pharo ecosystem (including Seaside), we all build on top of other people’s work, I was especially happy with Jochen Rick’s QRCode package (http://smalltalkhub.com/#!/~JochenRick/QRCode/). This is such a great piece of work !
It worked right out of the box in Pharo 7 (even though it is from 2013/2014), was well designed, easy to figure out, was well documented, had unit tests. I can’t say anything bad about it, it is as close to perfect as I have ever seen. So: thanks Jochen, you made my day !
It took me about 30 minutes to migrate one of my projects from 32bit Pharo 5 to 64bit 6.1 this afternoon. It has about 40 external dependencies so I thought it would take much longer to get everything sorted.
We chose to work on Diagrammer for multiple reasons. First, developers often need to create hand-built diagrams to communicate intentions, and an integrated experience should not require us to leave our environment to create them. At the same time, Diagrammer is an application that requires a widget and interactions, and thus it is a nice exercise for Bloc and Brick.
One requirement we had from the beginning was to make it work with any Bloc element. This means that the editing part had to be reasonably generic. To this end, we now have elements that can define visual editors. This is somewhat a combination between Magritte descriptions, and inspector extensions. An interesting side effect is that now we can edit visual properties when inspecting any element. In other words, we got the basic infrastructure of a UI painter. It looks like this: https://twitter.com/feenkcom/status/982656456968241152
The user interface essentially relies on two widgets: scrollable list and toggle button. While the visual look of the toggle button is inspired from material design, the most interesting part is that now we have an implementation for controlling looks per element instance. A key issue here is that looks can react to events coming from the element and inject visual attributes and possible even change behavior (for example, changing an icon while pressing a button). We will post more about looks soon.
We now also have a nice solution for overlays. For example, we have an overlay showing selection and an overlay for resizing elements.
Perhaps less obvious, Diagrammer also offers a basic infrastructure for the area of visual languages. As Diagrammer works with any Bloc elements, we can simply create dedicated visual elements. As an example, Diagrammer comes with an implementation of a UML class figure. Furthermore, as the functionality does not impose a specific model, custom language semantics can be mapped on visual actions.
There are several things to do still for it to become a mature solution. An important next step is to serialize a diagram scene in a reproducible manner. Currently, the diagram (or any element) can be exported as pdf (https://twitter.com/feenkcom/status/976580153802358786), svg (https://twitter.com/feenkcom/status/976578060429484032), png, gif or jpeg by directly using the low level canvas. However, for the diagram to be truly useful we need to store the result in either code or another reloadable form such as STON. Other future directions are related to figure controlling (for example, custom anchors or line bending points) and to enhanced editors.
To play with it, the easiest way is to download the new GT in a Pharo 6.1 image:
Coyote es un sistema de gestión integral de riesgos informáticos y operacionales, destinado a cualquier tipo de empresa que necesite manejar sus riesgos a través de una herramienta de seguimiento que permita controlarlos.
No sólo es necesario registrar e informar los riesgos que se detectan, sino que es imprescindible, para una adecuada gestión de los mismos, realizar el seguimiento pertinente y consensuar el tratamiento que se dará a los mismos.
Además, es importante disponer en todo momento de un tablero de control que permita conocer el estado de los riesgos de la compañía así como también cuáles están abiertos desde hace más tiempo, cuáles implican mayor impacto en la eventualidad de materializarse y cuáles pueden esperar ya que su impacto no es significativo.
Coyote permite realizar todas estas gestiones y facilita el trabajo de la Gestíón de Riesgos en forma constante con las nuevas funcionalidades que se van agregando al producto.
by Germán Arduino (email@example.com) at April 03, 2018 02:38 PM
The main changes are:
– There is a brand new demo with more examples and documentation. You
can find it here: https://mdl.ferlicot.fr
– There is a new concepts: The extensions. Extensions are not describe
by Material Design but are meant to help developers while building web
application. This release contains 3. A way to simplify the use of
dialogs, called “root dialog”, a resizeable left panel and a resizeable
right panel with tabs.
– There is a new widget: the progress widget
– New brushes to use premade typography and typogaphy styles
This release is tagged with v1.2.0 and I also introduced tags v1.2.x and
v1.x.x which are moving tags following patch and minor versions.
I have implemented the backend of FreeType using only FFI calls.
So the whole implementation is in the image side, the current plugin has a lot of problems handling the release of the pointers. The new implementation is using the mechanism that is already present in UFFI to release the Heap pointers, so it should be more stable and easier to modify if there is an issue.
The FT2Plugin is not used anymore in this version.
I have tested it in the different platforms, but beside OSX I have only made a smoke test. I need some users to try it, so I ask you if you can test in different installations.
We’re happy to announce a new version of the Highcharts JS Wrapper and the Web Stack hosted at https://github.com/ba-st/. This is a multi-release announcement of the following related project versions:
8 years dead this old blog; still hundreds of active subscribers to the old rss feeds; amazing. Seaside and Smalltalk never took over the world, but I still use them daily, guess I'm an old gray beard now, but it's a nice beard. :)
I’ve put some minutes summarizing the new APIs provided by the combination of the new File implementation and the Zn encoders. They all basically follow the decorator pattern to stack different responsibilities such as buffering, encoding, line ending conversions.
If you want to write files following a specific line ending convention, use the ZnNewLineWriterStream.
This stream decorator will transform any line ending (cr, lf, crlf) into a defined line ending.
By default it chooses the platform line ending convention.
lineWriter := ZnNewLineWriterStream on: aStream.
If you want to choose another line ending convention you can do:
6. About performance questions
Well, I’d say it we did it in the name of modularity. And yes, I believe that having separate responsibilities help in designing, testing and ensuring more easily the correctness of each of the parts in isolation.
I’ve done also some profiling and it does not look like we’ve lost in performance either (reading and decoding a 35MB file):
[file := Smalltalk sourcesFile fullName.
(File named: file) readStreamDo: [ :binaryFile |
(ZnCharacterReadStream on: (ZnBufferedReadStream on: binaryFile) encoding: ‘utf8’) next: binaryFile size.
I just managed to get Woden working with Vulkan, and OpenGL on Windows. Finally, smooth movement (My tearing was Linux failure). My only complain is that it takes too long on loading a Pharo image on Windows.
The Feenk team is working on on Diagrammer in Pharo. The idea is that developers should not have to leave the IDE - not even for drawing diagrams and they give a nice graphic preview on a more elaborate control of lines and figures in this tool with some screenshots on their twitter account.
– Diagrammer is a new engine for drawing diagrams based on Bloc. This is the first version, and we will continue working on it in the following weeks, so stay tuned for more news. This is also one of the first Bloc applications: https://twitter.com/feenkcom/status/972243179599794180
– Andrei put together a beautiful description of a scenario in which an application is molded interactively in the Playground & Inspector. The subject is face recognition, and the resulting code is both functional and explainable. This is intended as a tutorial material that shows what moldable development means and how it changes the way we program: https://twitter.com/feenkcom/status/972907051448979458
I pleased to announce you the first release of Cruiser: a tool to package your Pharo applications. The idea is to quickly convert an application from a development environment to a production one. A production environment means:
No writing on the disk
No access to the source code (by the shortcuts, debugger,…)