- Pharo-dev - lists.pharo.org

This week (49/2022) on the Pharo Issue Tracker
by Marcus Denker Dec. 9, 2022

Dec. 9, 2022

This week we merged 20 PRs. Blocks ====== Status: All tests green when compiling with ConstantBlockClosure (but the option is not yet enabled by default) Work continues to reducing the use of #home, this week by using #homeMethod instead of "home method" - 12008-Blocks-check-senders-of-compiledCode-can-we-use-homeMethod #12032 https://github.com/pharo-project/pharo/pull/12032 - Context-use-homeMethod #12007 https://github.com/pharo-project/pharo/pull/12007 - some trivial improvements batched (Compiler / Context / Blocks) #12035 https://github.com/pharo-project/pharo/pull/12035 - ConstantBlocks-fix-testIsNotTerminatedWhenItIsInsideLastTerminationMethod #12026 https://github.com/pharo-project/pharo/pull/12026 - ConstantBlocks-Fix-Announcement-Tests #12027 https://github.com/pharo-project/pharo/pull/12027 - Disablequickreturn in blocks #12053 https://github.com/pharo-project/pharo/pull/12053 Refactoring Engine ================== - Refactor make class abstract #12060 https://github.com/pharo-project/pharo/pull/12060 Features ===== - Environment: comment #allMethods, add #methods #12028 https://github.com/pharo-project/pharo/pull/12028 - help method for converting integers into correspâ¦ #11800 https://github.com/pharo-project/pharo/pull/11800 - Extend DiffMorph to make it navigable accross differences #11641 https://github.com/pharo-project/pharo/pull/11641 Fixes ===== - 12049-CI-failure-in-build-testSetUpMethodInSUnitTestsNeedsToBeInRunningProtocol #12051 https://github.com/pharo-project/pharo/pull/12051 - Fix #11995: Handle attempted creation of existing package gracefully #12048 https://github.com/pharo-project/pharo/pull/12048 - Should fix issue 11915 - Pharo compound shortcuts #11954 https://github.com/pharo-project/pharo/pull/11954 - [fix] Pharo issue # 11390: Browsing implementors/senders from source code editors doesn't browse expected selector #1298 https://github.com/pharo-spec/Spec/pull/1298 - Using version v3.0.4 of libgit to fix the 1.4.4 version in linux #1643 https://github.com/pharo-vcs/iceberg/pull/1643 - Fix Crash when invalid credentials #1642 https://github.com/pharo-vcs/iceberg/pull/1642 Cleanup ======= - Replacing baseColor method call from class to instance side #12030 https://github.com/pharo-project/pharo/pull/12030 - Fix lint issues #11978 https://github.com/pharo-project/pharo/pull/11978 - 12046 has non standard palette is always returning false #12047 https://github.com/pharo-project/pharo/pull/12047 Pharo10 ======= - [backport] CompiledCode: add #bytecodes #12031 https://github.com/pharo-project/pharo/pull/12031

1 1

[Compiler] A Small experiment with Syntax Errors
by Marcus Denker Dec. 8, 2022

Dec. 8, 2022

This is a small experiment about syntax errors when evaluating code. With #evaluate:, we can compile and run a DoIt, for example: Smalltalk compiler evaluate: '1+2' Imagine you evaluate a String, but it is actually not syntactically correct: Smalltalk compiler evaluate: '1+' We get an exception (while parsing), a SyntaxErrorDebugger is opened: This tool is not used often and is fairly odd, in practice we use it for two things: Look at the error message and use the (not easy to find) menu "debug calling process" to see where the eval was called to understand what went wrong (why we consructed a string of invalid code). The problem is that the tool is not easy to understand, and it is not easy to maintain as part of the debugger framework (it is a bit broken even now, especially wrt to editing and continue, which does not matter for DoIts, though). Could we no do better? Evaluating code means: - We parse the string to an AST - we translate the AST to a DoIt Method - we execute that method The error happens inside the parse phase: no method gets contructed, intead an exception is raised. There is quite some machinary to allow re-starting parsing after the error is fixed (see the exception ReparseAfterSourceEditing and how it is used, quite hard to understand). The idea that syntax errors are hard errors is quite natural. With batch compilers, there is some effort done to do some auto-repair. This was very useful in old times (punch cards!) to avoid seeing an aborted job the next morning just due to a missing comma. These days it is used to allow better error messages. But it is common to treat syntax errors as hard errors. This is seen as good as they are detected very early and the fact that compiling is not possible is seen as the goal for any kind of error. In the end, type systems try to extend this to non-syntactic problems: If a program is wrong, it should not run. If we call a method that does not exist, the program should not compile. What if we not follow this standard advice and go the exact opposite direction? Let's try: Our tools parse code after *every* keystroke. The resulting AST is used for syntax highlighting. Which means, we can parse the expression '1+â without any problem, if we use the same mode for the Parser: Smalltalk compiler options: #(+ optionParseErrors); parse: '1+' We see that the parser created an AST, with a ParseErrorNode as the argument of the message send +. This AST would used by the Syntax HighLighter, and for code completion. But it is in the end just the normal AST that the Compiler uses to compile source text to CompiledMethods. So can we not just implement the code in the compiler to compile this AST? The node implements the visitor pattern #acceptVisitor:, which calls visitParseErrorNode:. So we can add support to the compiler by just implementing OCASTTranslator>>#visitParseErrorNode: visitParseErrorNode: anErrorNode methodBuilder pushLiteralVariable: RuntimeSyntaxError binding; pushLiteral: anErrorNode; send: #signalSyntaxError: This just reads the global Variable RuntimeSyntaxError (which is subclass of Error), pushes the error node itself as an argument and sends #signalSyntaxError: signalSyntaxError: aNode "we use signalSyntaxError: instead of signal: so we can quickly check compiledMethods for syntax errors by checking the literals" ^(self new errorNode: aNode) signal To see what the compiler compiled for that expression, lets compile a DoIt method (this is what #evaluate: does to get a method to execute): compiledMethod := Smalltalk compiler noPattern: true; options: #(+ optionParseErrors); compile: '1+â So it did compile this bytecode, as expected: 49 <51> pushConstant: 1 50 <10> pushLit: RuntimeSyntaxError 51 <21> pushConstant: RBParseErrorNode() 52 <92> send: signalSyntaxError: 53 <60> send: + 54 <5C> returnTop To finish what #evaluate does, we can evaluate the compiledMethod (with a nil receiver): compiledMethod valueWithReceiver: nil arguments: #() and it works! The standard debugger opens, on the RunTimeSyntaxError: Can we do that by default for #evaluate? Go to OpalCompiler>>#evaluate and add the optionParseErrors line before compiling: ... options: #(+ optionParseErrors); doItMethod := self compile. ... If you now run Smalltalk compiler evaluate: '1+' It will open the normal debugger. What needs to be improved? - The error message is not shown other than in the debugger window title. (but all the infos to print a nice error in place is contained in the AST) - Maybe allowing to edit and proceed could be interesting (not that much for evaluate) (I will turn this into a blog post later) Marcus

1 0

Update Links on Pharo website
by Pierre Misse Chanabier Dec. 6, 2022

Dec. 6, 2022

Hello, I've noticed that a link to the pharo blog was missing & a user noticed the vision document link was broken. I did a couple of quick PR to fix them. Pierre

2 1

Unsubscribe from pharo-dev user doesn't exist
by Juan Miguel Mora Carrera Dec. 5, 2022

Dec. 5, 2022

Hi All. Sorry for the message totally unrelated to the topic, but it's been for a long time that I've been trying to unsubscribe from the list in this page: https://lists.pharo.org/empathy/list/pharo-dev.lists.pharo.org But it happens that my email account doesn't exist there, but still I'm receiving the emails. I guess my email got there via a migration from a previous list years ago. Please, could you tell me how might I unregister from the list? Thanks. Juan Miguel

1 0

This week (48/2022) on the Pharo Issue Tracker.
by Marcus Denker Dec. 2, 2022

Dec. 2, 2022

This week we merged 34 PRs. Features ======== - New refactoring changes preview presenter #11887 https://github.com/pharo-project/pharo/pull/11887 - Creating a method to print the "full" debug stack #11983 https://github.com/pharo-project/pharo/pull/11983 - 11544 enhance socket to show meaningful errors #11921 https://github.com/pharo-project/pharo/pull/11921 - Adding debugger extension visitor to display variables from extensions (as Chest) #402 https://github.com/pharo-spec/NewTools/pull/402 - add a Method Source View for Context #440 https://github.com/pharo-spec/NewTools/pull/440 Blocks ====== - Tests for clean and constant blocks #12015 https://github.com/pharo-project/pharo/pull/12015 - Support #isReturnSpecial on CompiledBlock #11987 https://github.com/pharo-project/pharo/pull/11987 - 11966-Implement-BlockClosurehomeMethod-without-using-home #12000 https://github.com/pharo-project/pharo/pull/12000 - StDebugger-stackSelectionMethodContext-homeMethod #445 https://github.com/pharo-spec/NewTools/pull/445 - use Context>>#homeMethod #12023 https://github.com/pharo-project/pharo/pull/12023 - 11967-Implement-findMethodContextSuchThat #12013 https://github.com/pharo-project/pharo/pull/12013 - ConstantBlock-fix-DebuggerTest #12024 https://github.com/pharo-project/pharo/pull/12024 Fixes ===== - 11844-Renaming-a-package-loses-all-the-package-extensions #11982 https://github.com/pharo-project/pharo/pull/11982 - [Compiler] fix code generation when compiling syntax errors: EnglobingError #11947 https://github.com/pharo-project/pharo/pull/11947 - fix var lookup in debugger when block pushed on stack #11989 https://github.com/pharo-project/pharo/pull/11989 - Fix print on recursive array #11916 https://github.com/pharo-project/pharo/pull/11916 - 11937-Cycling-of-Halos-does-not-work-anymore #12016 https://github.com/pharo-project/pharo/pull/12016 - Fixed #11946. Added SequenceableCollection>>truncatedToSize and a trait to test it #11988 https://github.com/pharo-project/pharo/pull/11988 - Fix: "Copy stack to clipboard" doesnt copy the whole stack #442 https://github.com/pharo-spec/NewTools/pull/442 Speed ===== - Fix slow execution time when using CharacterSet or CharacterSetCompleâ¦ #11991 https://github.com/pharo-project/pharo/pull/11991 - 12006-Performance-Regression-in-Fuel-Serialization-of-Blocks--CompiledMethods #12022 https://github.com/pharo-project/pharo/pull/12022 External Packages ================= - Updating version of tonel #12003 https://github.com/pharo-project/pharo/pull/12003 - Integrate Roassal3 v0.9.9k #12012 https://github.com/pharo-project/pharo/pull/12012 Cleanup Help ============ - Fix #11949 less help class #11950 https://github.com/pharo-project/pharo/pull/11950 - Fix spechelp problem #11999 https://github.com/pharo-project/pharo/pull/11999 - Fix 11994 Another pass to remove help classes. Waiting for the integrâ¦ #11996 https://github.com/pharo-project/pharo/pull/11996 - Removing help support #12001 https://github.com/pharo-project/pharo/pull/12001 - Removing remaing Help Topic references #444 https://github.com/pharo-spec/NewTools/pull/444 - remove help processor #443 https://github.com/pharo-spec/NewTools/pull/443 - remove Spec2-Help #1333 https://github.com/pharo-spec/Spec/pull/1333 Trival Cleanups =============== - Cleanup STON classes who show lint issue on categorization of #initiaâ¦ #11964 https://github.com/pharo-project/pharo/pull/11964 - add tag "system" #11985 https://github.com/pharo-project/pharo/pull/11985 - 12009-ProperMethodCategorizationTesttestNoUncategorizedMethods-fails-on-CI #12010 https://github.com/pharo-project/pharo/pull/12010 - Trivial-clean-Morph #12025 https://github.com/pharo-project/pharo/pull/12025

1 0

Digital Twin applied to Software
by Aik-Siong Koh Nov. 30, 2022

Nov. 30, 2022

Hi: I have a novel idea "Digital Twin applied to Software". See attached slides. It points to the future of improved programming productivity and reliability. Let me know what you think. Thanks, Aik-Siong Koh http://ar-cad.com Abstract Digital Twin applied to Software Aik-Siong Koh askoh.com There has been a major dichotomy in computing right from the beginning: Statically Typed vs Dynamically Typed programming languages. The former languages produce fast executables but are inflexible to program. The latter are just the converse. This dichotomy has been frustrating to programmers who always feel they have to make sacrifices when making a choice. It also often leads to futile language wars. The Digital Twin concept was introduced in engineering where a physical system is modeled digitally in geometry, simulation and other information. The concept has proven so successful that it is being applied to almost everything in engineering from simple mouse traps to complex whole cities. It occurred to the author that this concept can be extended to software too. For example, execution in C++ is famously fast. But development in C++ is notoriously difficulty because of language complexity and long build times. A flexible digital twin can be a program written in Smalltalk which is famous for live programming. "Development at the speed of thought" is the motto and is real. What is gained by this duplication? Firstly, the flexible twin can be use to explore new algorithms, features, solutions and fix bugs quickly. Only desired codes are translated to C++ manually or automatically. Secondly, the two programs can check each other so that bugs are reduced significantly. These two gains will define future programming productivity and quality. The Digital Twin concept will also drive the automatic translation of the flexible language to the fast language. Bio Dr Aik-Siong Koh has a PhD from The University of Texas at Austin where he programed in FORTRAN to simulation mechanical systems. While teaching at Texas Tech University and Nanyang Technological University, he developed interest in Multibody Dynamics. To develop his own Multibody Dynamics simulator, he researched for the most productive programming language and discovered Smalltalk. The live programming capabilities of Smalltalk permitted him to build a successful simulator which he then proceeded to commercialize. His later experience with C++ at Mechanical Dynamics and MathWorks gave him the idea of Digital Twin for Software.

3 3

This week (46/2022) on the Pharo Issue Tracker
by Marcus Denker Nov. 25, 2022

Nov. 25, 2022

We merged 18 PRs Lots of improvements related to BlockClosures this week. First some helper methods on the AST: - #hasNonLocalReturn: check if there is a non-local return - #isConstant: Blocks of the kind [#justSomeLiteral] - #constantValue: return that literal (and nil for empty [] ) - #numArgs for RBBlockNode, as we have already for BlockClosure "[:a | ] sourceNode numArgs" Some improvements for isClean: - unify between AST and BlockClosure - more tests - inlined blocks can be clean, important as it is recursive: [true ifTrue: []] should be clean - cleanup code in CleanBlock, receiver is known to be nil Compiler support for ConstantBlockClosure: - We can specialize clean blocks of the kind [#justSomeLiteral] to execute faster - add ConstantBlockClosure, add compiler support, active when compiling with clean blocks enabled Compiler support for full block without outer context: - we only need the outerContext for non-local returns. - add support to IRBuilder for full blocks without outer context - implement compiler support (option #optionBlockClosureOptionalOuter, false for now) Quick return for Blocks: - Compile quickreturn for CompiledBlock, just like CompiledMethod (e.g. for [^1]). - speeds up execution a little (but of course not creation) Block Closures ============== - AST: add a recursive #hasNonLocalReturn and #isConstant #11882 https://github.com/pharo-project/pharo/pull/11882 - add #numArgs to RBBlockNode #11902 https://github.com/pharo-project/pharo/pull/11902 - CleanBlock cleanup code: there should be no receiver ivar #11884 https://github.com/pharo-project/pharo/pull/11884 - 11881-RBBlockNodeisClean-takes-every-optimized-block-to-be-not-clean #11890 https://github.com/pharo-project/pharo/pull/11890 - 1883-CleanBlockChecker-does-not-recurse-into-the-blocks #11900 https://github.com/pharo-project/pharo/pull/11900 - ConstantBlockClosure: active when compiling with clean blocks enabled #11894 https://github.com/pharo-project/pharo/pull/11894 - CompiledBlocks: compile quick returns #11907 https://github.com/pharo-project/pharo/pull/11907 - IRBuilder: add support for outerContext flag for Closure creation #11905 https://github.com/pharo-project/pharo/pull/11905 - 11911-Compiler-add-compiler-option-for-outerContextNeeded #11917 https://github.com/pharo-project/pharo/pull/11917 Fixes ===== - Register-as-basicInspector #431 https://github.com/pharo-spec/NewTools/pull/431 - 11803 return value of inspect should be the receiver and not a sp window presenter #11886 https://github.com/pharo-project/pharo/pull/11886 - Fixes #429, VersionBrowser: left pane empty #430 https://github.com/pharo-spec/NewTools/pull/430 - Turn off ReLongMethodsRule for test methods #11892 https://github.com/pharo-project/pharo/pull/11892 - ClassParser: Implement #asSlot to return a correct Slot instances for complex slots #11898 https://github.com/pharo-project/pharo/pull/11898 - Fixes #11802 - Adds full consistency checks to class Time #11891 https://github.com/pharo-project/pharo/pull/11891 - Fixing to correctly get the VM for running the tests #11897 https://github.com/pharo-project/pharo/pull/11897 - Fixes #429, VersionBrowser: left pane empty #430 https://github.com/pharo-spec/NewTools/pull/430 Cleanup ======= - 11810-FT2Handle-classstartUp-compiled-code-on-image-startup #11811 https://github.com/pharo-project/pharo/pull/11811 Comments ========= - fixing comments in package Regex #11888 https://github.com/pharo-project/pharo/pull/11888

2 4

Improved Inspectors for Blocks
by Marcus Denker Nov. 25, 2022

Nov. 25, 2022

The inspectors for blocks are now a bit improved: 1) CompiledBlock. This now is more in sync with CompiledMethod and shows - the homew method code with the block highlighted - the AST of the block - the IR if the block Currently, we compile every non-optimized block to a full block that created by a bytecode from a CompiledBlock (which itself is stored as a literal). inspect âCompiledBlock allInstancesâ to see the new inspector: 2) BlockClosure itself, e.g inspect some block in the workspace. This gets more important as we soon will have pre-compiled subclasses of BlockClosure as method literals (and then just execute pushLiteral: to âcreateâ the block). A nice way to play with these is: CompilationContext optionConstantBlockClosure: true. OpalCompiler recompileAll. some 2500 of the blocks are now compiled statically. Inspect: ConstantBlockClosure allSubInstances The inspector shows the same (home method with highlight, IR, AST) But we can do even better: CompilationContext optionCleanBlockClosure: true. OpalCompiler recompileAll. Another 7500 blocks can be statically compiled, inspect CleanBlockClosure allInstances These are not yet the default, as we have to carefully analyse the places where we now assume that blocks know the outerContext and receiver. (in the example above you see one of these: Announcementsâ¦). You can follow these issues to see what still needs to be done: [Meta] Steps needed for ConstantBlocks #11933 https://github.com/pharo-project/pharo/issues/11933 [Meta] Steps needed for CleanBlocks #11195 https://github.com/pharo-project/pharo/issues/11195 Marcus

1 0

This week (47/2022) on the Pharo Issue Tracker.
by Marcus Denker Nov. 25, 2022

Nov. 25, 2022

We merge 33 PRs this week. Features / Enhancements ========= - Introducing new icons #11896 https://github.com/pharo-project/pharo/pull/11896 - Enhancement: PackageManifest with an own system icon #11956 https://github.com/pharo-project/pharo/pull/11956 - ReNotOptimizedIfNilRule #11932 https://github.com/pharo-project/pharo/pull/11932 - Sync #basicInspect and inspect #11899 https://github.com/pharo-project/pharo/pull/11899 Blocks / Compiler ======= Constant blocks now implement correct error handling wrt to number of arguments, we now have an option to enable compiling constant block (#optionConstantBlockClosure) and can recompile the whole system with compiling constant blocks. - 11912-Compiler-add-option-for-constant-blocks #11927 https://github.com/pharo-project/pharo/pull/11927 - Blocks: pcInOuter-not-Debugging #11951 https://github.com/pharo-project/pharo/pull/11951 - Class comments for Compiler classes (mostly exceptions) #11948 https://github.com/pharo-project/pharo/pull/11948 - Some smaller fixes/cleanups related to Blocks #11936 https://github.com/pharo-project/pharo/pull/11936 - Context-print-no-isClean-check #11922 https://github.com/pharo-project/pharo/pull/11922 - 11901-ConstantBlockClosure-raise-error-if-called-with-wrong-number-of-args #11919 https://github.com/pharo-project/pharo/pull/11919 - Better-CompiledCode-Inspector: highlight in source #436 https://github.com/pharo-spec/NewTools/pull/436 - Inspect-CompiledBlock-IR #435 https://github.com/pharo-spec/NewTools/pull/435 Fixes ===== - fix OSWIndowDriver shutdown while saving #11831 https://github.com/pharo-project/pharo/pull/11831 - do not rebuild all Calypso tools at each selection change #11952 https://github.com/pharo-project/pharo/pull/11952 - EpHasImpactVisitor>>visitProtocolRemoval: handle protocols that only contain trait methods. #11942 https://github.com/pharo-project/pharo/pull/11942 - RubTextEditor: Bind the MENU key to open the context menu #11659 https://github.com/pharo-project/pharo/pull/11659 - Fixes #11925, ExternalBrowser does not show class definition from ST files Bug #11929 https://github.com/pharo-project/pharo/pull/11929 - 11762 cannot view st file content with code file browser #11924 https://github.com/pharo-project/pharo/pull/11924 - Fix debugger to update debugger extensions when a context is selected in the stack + fixing bytecode extension #405 https://github.com/pharo-spec/NewTools/pull/405 Git Support ========== - Forget repository iceberg error on windows #1633 https://github.com/pharo-vcs/iceberg/pull/1633 - Fixing the error handling. #1631 https://github.com/pharo-vcs/iceberg/pull/1631 - Migrate GT inspector extensions to new tools model #1630 https://github.com/pharo-vcs/iceberg/pull/1630 CI Setup ======== - Fixing runKernelTests to make it work with alternating VMs #11935 https://github.com/pharo-project/pharo/pull/11935 - Improve bootstrap.sh #11824 https://github.com/pharo-project/pharo/pull/11824 Cleanup ======= - Remove old comment editors #11945 https://github.com/pharo-project/pharo/pull/11945 - Cleanup on The package TestRunner #11509 https://github.com/pharo-project/pharo/pull/11509 Trivial Cleanups =============== - Cleanup TypingVisitor>>#initialize method category #11958 https://github.com/pharo-project/pharo/pull/11958 - Clenaup MemoryLogger>>#initialize #11962 https://github.com/pharo-project/pharo/pull/11962 - Cleanup: Fix lint TFTestCallbackExceptionHandler>>#initialize #11960 https://github.com/pharo-project/pharo/pull/11960 - simplify some users of #ifNil:ifNotNil: to use not nil arg #11930 https://github.com/pharo-project/pharo/pull/11930 - Use-optimizable-ifTrue #11923 https://github.com/pharo-project/pharo/pull/11923 - remove the unused <return:> pragma in spotter #434 https://github.com/pharo-spec/NewTools/pull/434 - avoid #asSymbol for the defaultFont. fixes #1329 #1330 https://github.com/pharo-spec/Spec/pull/1330

1 0

[ Smalltalkers wanted... ]
by stephane ducasse Nov. 23, 2022

Nov. 23, 2022

We are looking for Smalltalkers for adesso insurance solutions GmbH. Remote work is possible and German language is required (at least B2). Links: https://www.adesso.de/de/jobs-karriere/unsere-stellenangebote/Software-Engi… <https://www.adesso.de/de/jobs-karriere/unsere-stellenangebote/Software-Engi…> https://www.linkedin.com/jobs/view/3353601212/ <https://www.linkedin.com/jobs/view/3353601212/> Text: About the job FÃ¼r unsere Tochtergesellschaft, die adesso insurance solutions GmbH, suchen wir einen Software Engineer Smalltalk (all genders) Als Teil der adesso group bÃ¼ndelt die adesso insurance solutions GmbH das eigene Produktportfolio fÃ¼r den Versicherungsmarkt und treibt innovative Software-LÃ¶sungen in diesem Umfeld voran. Wir sind ein Team aus Ã¼ber 200 engagierten Kollegen und Kolleginnen. Und du kannst ein Teil davon werden. DEINE ROLLE - DAS WARTET AUF DICH Du kennst dich mit objektorientierter Programmierung aus? Smalltalk ist fÃ¼r dich eine Programmiersprache mit Tiefgang? Dann suchen wir genau dich als Software Engineer fÃ¼r unser Professional Services Team im Umfeld des Pensionsmanagements. Bei uns arbeitest du gemeinsam im Team mit Entwicklern, Testern und Projektmanagern an den besten LÃ¶sungen fÃ¼r unsere CollPhir-Software. Ãbrigens: Wir sind langjÃ¤hriger Sponsor der EUSG. Deine Aufgaben Â· Auf Basis von Smalltalk programmierst du neue Anforderungen und Erweiterungen. Â· Neue Anforderungen unserer CollPhir-Software setzt du um. Â· Du analysierst, konzipierst und realisierst eigenstÃ¤ndig kundenspezifische Erweiterungen. Â· Im Third-Level unterstÃ¼tzt du das Support-Team bei technischen Fragen zur Software. Â· Die Dokumentation und das Beheben von Fehlern gehÃ¶ren auch zu deinen Aufgaben. Deine Skills - Das Bringst Du Mit Â· Du verfÃ¼gst Ã¼ber einen technischen Hochschulabschluss (Informatik, Ingenieurwissenschaften, Mathematik, Physik, o.Ã.) oder hast bereits Erfahrung in der Softwareentwicklung mit Smalltalk gesammelt Â· Du hast keine Scheu vor Datenbankmanagementsystemen und verfÃ¼gst Ã¼ber â zumindest rudimentÃ¤res â Wissen in technologisch benachbarten Bereichen (z.B. Java) Â· Du bist neugierig und lernbereit, denn bei uns wird Weiterentwicklung sowohl technologisch als auch persÃ¶nlich groÃgeschrieben Â· Deine Deutschkenntnisse sind sehr gut und mindestens auf Level B2 CHANCENGEBER - WAS ADESSO AUSMACHT Unser Versprechen: Du wirst dich bei uns wohlfÃ¼hlen! Kollegial, familiÃ¤r und auf AugenhÃ¶he â wir leben Austausch, Teamgeist und einen respektvollen Umgang miteinander. Das und viel mehr steht fÃ¼r unser ganz besonderes Wir-GefÃ¼hl. FÃ¼r das es sogar ein Wort gibt: adessi. Denn wir sind alle adessi ab Tag Eins und bei uns bist du von Anfang an Teil des Teams. Unsere Kultur und das Zusammenarbeiten sind geprÃ¤gt von gegenseitiger WertschÃ¤tzung, Anerkennung und UnterstÃ¼tzung. Das verbindet uns hierarchieÃ¼bergreifend â auch im Home-Office. Jeder und jedem adessi stehen alle MÃ¶glichkeiten zur persÃ¶nlichen und beruflichen Entwicklung offen. Unser umfangreiches Trainings- und Weiterbildungsangebot sorgt dafÃ¼r, dass deine Entwicklung bei uns nicht stillsteht. Denn Chancengeber zu sein, das liegt in unserer DNA. Â· Welcome Days - Zwei Tage zum Reinkommen und Netzwerken Â· Bis zu drei Tage mobiles Arbeiten â keine Frage von Pandemien, sondern von Ãberzeugung Â· Deine Entwicklung - Ã¼ber 260 Lern- und Trainingsthemen Â· Events - fachlich und mit SpaÃfaktor Â· Hemden-/Blusenreinigung - zweimal die Woche frisch aufgebÃ¼gelt Â· SportfÃ¶rderung - Zuschuss zum Fitnessstudio und mehr Ã¼ber qualitrain sowie Ãbernahme der Platzmiete fÃ¼r die Sporthalle Â· adesso Mind - Das adesso-Programm rund um Mindfulness Â· PrÃ¤mien fÃ¼r Mitarbeitende - eine Vielzahl an PrÃ¤mien fÃ¼r zusÃ¤tzliches Engagement Â· Auszeitprogramm - Raum fÃ¼r deine persÃ¶nliche Lebensplanung KONTAKT Du bist offen fÃ¼r neue und anspruchsvolle Aufgaben? Dann sende uns deine Bewerbungsunterlagen (inkl. deines CV, deiner Arbeits- und Studienzeugnisse sowie deiner Gehaltsvorstellungen und dem frÃ¼hestmÃ¶glichen Eintrittstermin) vorzugsweise Ã¼ber unser Webformular. Â· Sina MÃ¶schl Â· Recruiting Â· +49 231 7000 7100 Best wishes, -- FÃ©lix Madrid adesso insurance solutions GmbH Agrippinawerft 26 50678 KÃ¶ln T +49 221 27850-355 M +49 152 38869-784 F +49 221-27850-500 E felix.madrid(a)adesso-insurance-solutions.de <mailto:felix.madrid@adesso-insurance-solutions.de> www.adesso-insure.de <http://www.adesso-insure.de/>

1 0