In short, three different fellowships are available:

1. Research Fellowship: For individuals without a PhD who are considering pursuing research studies.
2. PhD Scholarship: For those who wish to pursue a PhD in Switzerland for a period of 3+ years.
3. Post-Doc Scholarship: For individuals with a PhD who are looking to spend one year in Switzerland conducting postdoctoral research.

Please note that all fellowships are intended for individuals who have not previously spent time in Switzerland. Consequently, if you are awarded one of these fellowships, you will be ineligible to apply for the others in the future as you technicaly already have a Phd or Postdoc in Switzerland.

Let’s see each one of them in dettail:

Research Fellowship

Research Fellowships are 12-month programs aimed at highly qualified postgraduate researchers from all academic disciplines. Applicants must have obtained a master’s degree or equivalent by July 31, 2024, except for ETH Zurich applicants, who must meet this requirement by June 30, 2024. Candidates should be born after December 31, 1988. The application requires a support letter from an academic host professor at a Swiss university, including a brief CV (maximum 2 pages), explaining their willingness to supervise and support the research. This letter differs from the confidential recommendation letter also required. Additionally, applicants must submit a research proposal with a defined time frame. Notably, this fellowship is not available to those who already hold a PhD degree

PhD Scholarship

PhD Scholarships are designed for highly qualified PhD students from all academic disciplines, offering funding for 12 to 36 months, extendable in three 12-month increments based on academic progress. Applicants must have obtained a master’s degree or equivalent by July 31, 2024, except for ETH Zurich applicants, who must meet this requirement by June 30, 2024. Eligible candidates should be born after December 31, 1988. The application requires a support letter from an academic host professor at a Swiss university, including a brief CV (maximum 2 pages), detailing their commitment to supervise and support the PhD throughout its duration. If an assistant professor supports the application, a full professor must co-sign the letter. This support letter is distinct from the confidential recommendation letter also required. For PhD studies at a University of Applied Sciences, an additional support letter from a faculty member of the host research university is mandatory. The doctoral degree must be awarded by a research university. A detailed research proposal with a defined time frame is the centerpiece of the application and requires thorough attention.

Post-Doc Scholarship

Postdoctoral Scholarships are 12-month programs aimed at highly qualified early career scientists from all scientific fields. Eligible candidates must have completed their PhD between December 31, 2020, and July 31, 2024 (June 30, 2024, for ETH Zurich), and primarily for those who have not previously studied in Switzerland. The program does not fund sabbaticals. Applicants need a support letter from an academic host professor at a Swiss university, including a brief CV (maximum 2 pages), explaining their willingness to supervise the research. Former PhD mentors and co-directors for co-tutelle PhDs cannot be supervisors. A detailed research proposal with a timeframe is the centerpiece of the application. This scholarship is exclusively for full-time postdoctoral research in Switzerland, prohibiting fieldwork outside the country, and recipients are expected to reside in Switzerland during the grant period. For double doctorates, the date of the first degree is considered. The scholarship is not valid for mixed research conducted partly in Switzerland and partly in another country.

Where to find more Information

The official link of the scholarship contains all the relevant information and is the “GO TO” resources:

• https://www.sbfi.admin.ch/sbfi/en/home/education/scholarships-and-grants/swiss-government-excellence-scholarships.html

Additionally, each country has specific information and details regarding the application procedure, which can be found at the following link.

• https://www.sbfi.admin.ch/dam/sbfi/en/dokumente/2022/07/all-countries.pdf.download.pdf/2023_ESKAS_all_country_contacts_A_to_Z_for_application_documents.pdf

I recommend relying on the official information provided at the link above. The program itself warns about potential scams, and while there are numerous YouTube videos on the topic, some are generated by ChatGPT and others are, for lack of a better word, “dubious.” Here, I share videos from two YouTubers who, in my opinion, offer a reliable overview of the program. From Jama, part 1:

And part 2:

As well as from Aatiya:

My personal suggestions:

If you are interested in applying for a Phd or Postdoc in Switzerland, here are my personal suggestions:

1. Start Early (Paperwork): The application process is deliberately complex to filter out unmotivated candidates. The responsibility for managing the paperwork falls entirely on you, so begin early to ensure you have ample time to complete everything accurately.
2. Start Early (Connections in Switzerland): A critical aspect of the application is obtaining a support letter from a professor in Switzerland who is willing to endorse your candidacy and confirm that your proposal aligns with their and their institution’s research. Building these connections early is essential.
3. Start Early (Your Research Proposal): Develop a meaningful and well-written research proposal as soon as possible. Without a solid proposal, it will be challenging to secure support from a professor. You are solely responsible for writing this proposal. Once you have a polished version formatted according to the required templates, use it as your business card when reaching out to potential professors in Switzerland. Without this document, your communication is likely to be ignored or flagged as spam.

In other words, your commitment and the importance of contacting your potential supervisor as early as possible, armed with all the relevant information, cannot be overstated. This official video from the program provides additional valuable suggestions:

In addition, please note that each professor will not/cam not endorse more then one (or two) candidates per year. Therefore many of the request may simply be not answered.

Can I help you further for your Phd or Postdoc in Switzerland?

It really depends. For this specific grant you (the applicant) are really responsible for doing the heavy lifting as well as for dealing with the dettails. As for the rest, (i) if you believe that you have what it takes for this fellowship, (ii) you fulfill all the requirements, (iii) you have a nice idea to pursue and (iv) it is related to one of the following areas:

1. Internet of Things (IoT): Refers to the network of interconnected devices and objects that can communicate and share data. IoT enables smart homes, industrial automation, and more.
2. Extended Reality (XR): Encompasses virtual reality (VR), augmented reality (AR), and mixed reality (MR). XR technologies blend digital content with the real world, enhancing user experiences.
3. Human Behavioral Informatics: The study of human behavior using data analytics and computational methods. It involves understanding patterns, preferences, and decision-making based on digital interactions.
4. Computer Vision: A field of artificial intelligence that focuses on enabling machines to interpret visual information from images or videos. Applications include facial recognition, object detection, and medical imaging.
5. Language Processing: Also known as natural language processing (NLP), it involves teaching computers to understand and generate human language. NLP powers chatbots, language translation, and sentiment analysis.
6. Security and Privacy: Addresses safeguarding data, systems, and networks from unauthorized access or breaches. It includes encryption, authentication, and privacy-preserving techniques.
7. Big Data Processing: Deals with managing and analyzing large volumes of data. Technologies like Hadoop and Spark enable efficient processing of massive datasets.
8. Distributed Systems: Involves designing and managing systems that run on multiple interconnected computers. Examples include cloud computing, peer-to-peer networks, and distributed databases.
9. Serverless Computing: A cloud computing model where developers focus on writing code without managing servers. Serverless platforms automatically scale resources based on demand.
10. Digital Decision Making: The process of using data-driven insights and algorithms to make informed choices in various domains, such as business, healthcare, and finance.

You can consider dropping me a line! Are you still finishing your thesis instead? These guides may help!

Good Luck!

The post Phd or Postdoc in Switzerland for International Students: On Swiss Government Excellence Scholarships appeared first on Francesco Lelli.

In short Coupling, Cohesion and Granularity are part of SOA Design Principle and they can be summarized as follows:

• Service Coupling:
  • Definition: Refers to the degree of interdependence between two business processes.
  • Preferable State: Weak coupling is favored in SOA, indicating lower dependency for increased flexibility and maintainability.
• Service Cohesion:
  • Definition: Represents the degree of functional relatedness and focus of operations within a service.
  • Preferable State: Strong cohesion is preferred in SOA, indicating that a service should encapsulate closely related and well-defined functionalities.
• Service Granularity:
  • Definition: Denotes the scope of functionality exposed by a service.
  • Preferable State: Coarse granularity is recommended in SOA, suggesting that services should provide broad functionalities to address specific needs, promoting reusability.

Service Coupling:

Service Coupling is a critical design principle that examines the degree of interdependence between any two business processes or services within a system. It essentially evaluates how tightly or loosely these services are connected and the implications of changes in one on the others.

Characterized by the level of dependency, tight coupling signifies a strong interconnection where modifications in one service may necessitate corresponding changes in others. Conversely, weak coupling is the preferred state in SOA design. Weak coupling implies a lower level of dependency, allowing for greater flexibility, scalability, and ease of maintenance. Services with weak coupling can evolve independently, reducing the risk of unintended consequences when modifications or updates are made.

The benefits of weak coupling extend to the adaptability of the architecture to changes in business requirements. Services that are loosely coupled are more resilient to alterations, ensuring that adjustments in one part of the system do not propagate unexpectedly to other interconnected services.

For example, a service employing standardized interfaces and protocols can interact with other services more loosely, minimizing the impact of changes in one service on others. Achieving weak coupling often involves defining clear service interfaces, minimizing direct dependencies, and utilizing standards to facilitate interoperability between services. In essence, Service Coupling is a foundational principle in SOA design that promotes a modular, adaptable, and scalable architecture.

Service Cohesion:

Service Cohesion stands as a pivotal design principle governing the internal organization and functional relatedness within an individual service. It delves into the degree to which the operations encapsulated within a service are logically connected and focused on a specific set of functionalities.

Characterized by its emphasis on functional relatedness, strong cohesion is the ideal state for services in SOA. A service exhibiting strong cohesion encapsulates a well-defined and closely related set of functionalities, ensuring that its operations are united by a common purpose. This design approach enhances the service’s clarity, maintainability, and usability, as all contained functionalities contribute to a coherent and unified business capability.

In contrast, weak cohesion suggests a service with disparate functionalities that may not be logically connected, leading to a lack of clarity and potentially hindering the service’s effectiveness. Strong cohesion, on the other hand, facilitates a service’s reusability, as the encapsulated functionalities are designed to work together seamlessly, promoting a modular and extensible architecture.

For example, a service responsible for order processing should ideally encapsulate functionalities such as order validation, payment processing, and inventory management, exhibiting strong cohesion by focusing on a cohesive set of operations related to order fulfillment.

Achieving strong cohesion often involves careful analysis of the business processes and ensuring that the functionalities grouped within a service share a common context and purpose. This principle contributes to the creation of services that are not only well-defined and purposeful but also conducive to building a scalable and adaptable SOA.

Service Granularity:

The concept of Service Granularity plays a crucial role in defining the scope of functionality exposed by a service. It is essentially a measure of how broad or specific a set of functionalities needs to be in order to address a particular business need. The degree of granularity directly impacts the reusability, flexibility, and efficiency of the services within the architecture.

In SOA, the preferable state for Service Granularity is characterized by a tendency towards coarse granularity. Coarse-grained services encapsulate broader and more encompassing functionalities, capable of addressing significant business requirements in a single service invocation. This design approach promotes simplicity, reduces the number of service interactions, and facilitates easier maintenance.

Conversely, fine-grained services expose narrower sets of functionalities, potentially requiring multiple service invocations to fulfill a specific business operation. While fine granularity may seem intuitive for certain scenarios, it can lead to increased communication overhead and complexity, making the system more susceptible to performance issues and maintenance challenges.

For example, a coarse-grained service responsible for customer management might encompass functions such as creating, updating, and deleting customer profiles, providing a comprehensive set of functionalities within a single service interface.

Achieving the right level of granularity involves careful consideration of the business context and requirements. Coarse granularity is favored as it enhances the potential for service reuse, reduces the impact of changes on service interfaces, and aligns with the overarching goal of creating a modular and scalable architecture in SOA. Striking a balance between granularity and functionality is key to building an effective and adaptable service-oriented system.

Unlock the power of Service Oriented Architecture (#SOA )! Learn how #service Coupling Cohesion, and Granularity influence flexibility and #scalability in your #System . #softwaredevelopment #programming #API
Share on X

Service Oriented Architecture (SOA) Design Principle and Application Programming Interfaces (APIs)

The concepts of Service Coupling, Service Cohesion, Service Granularity, and APIs (Application Programming Interfaces) are intricately related in the context of designing and implementing a Service Oriented Architecture (SOA) or any modular and scalable system. APIs act as the external interface for services, and their design choices have a direct impact on the level of coupling, the cohesion within services, and the granularity of functionalities exposed. A well-thought-out API strategy is crucial for realizing the principles of a modular, scalable, and adaptable Service Oriented Architecture.

APIs and SOA operate at different levels of abstraction and have distinct purposes within the realm of software architecture. The distinction in their level of abstraction is rooted in their design principles, scope, and intended use. APIs are considered more low-level than SOA because they provide detailed interfaces for developers to interact with specific functionalities, while SOA operates at a higher level, focusing on the overall organization and alignment of services within a system. APIs are tools that facilitate the implementation of SOA principles at a more granular level.

This specific article focus on SOA design principles; if you want to know more on how to design a good API you can find more information here.

The post Service Oriented Architecture (SOA) Design Principle: Coupling, Cohesion, and Granularity appeared first on Francesco Lelli.

Design patterns serve several important purposes in software development:

1. Reusability: They encapsulate proven solutions to common problems, making it easier for developers to reuse these solutions in different parts of their code or in different projects.
2. Abstraction: Design patterns provide a higher-level abstraction that helps developers think about and communicate the structure of their code more effectively. They provide a common language and framework for discussing design decisions.
3. Maintainability: Using design patterns can improve the maintainability of software because they promote well-structured and organized code. Developers can more easily understand and modify code that follows established patterns.
4. Scalability: Patterns can help ensure that software is designed in a way that allows it to scale and adapt to changing requirements without requiring major redesigns.
5. Community Knowledge: Design patterns are well-documented and widely recognized within the software development community. This means that developers can leverage the collective wisdom and experience of the community when applying these patterns.

As the term software embrace a very large domain, there are several categories of design patterns. Each one is specialized for a particular portion portion of the code. These patterns includes:

1. Creational Patterns: These patterns deal with object creation mechanisms, trying to create objects in a manner suitable to the situation. Examples include the Singleton, Factory Method, and Abstract Factory patterns.
2. Structural Patterns: Structural patterns focus on defining the composition of classes and objects. Examples include the Adapter, Bridge, and Decorator patterns.
3. Behavioral Patterns: Behavioral patterns are concerned with the interaction and communication between objects. Examples include the Observer, Strategy, and Command patterns.
4. Architectural Patterns: These are high-level patterns that deal with the overall structure of an application. Examples include the Model-View-Controller (MVC), Model-View-ViewModel (MVVM), and Layered Architecture patterns.
5. Concurrency Patterns: These patterns address issues related to managing concurrent access to shared resources in multi-threaded applications. Examples include the Mutex, Semaphore, and Read-Write Lock patterns.

Design patterns are not one-size-fits-all solutions, and they should be applied judiciously based on the specific requirements and constraints of a software project. Experienced developers use their knowledge of design patterns to make informed decisions about when and how to apply them to solve particular problems.

The list of pattern is long and is also evolving as the software developer community evolve. At the Some time pattern like facade, adapter/wrapper, proxy and observer stand the test of time and are the most known among developers. Let’s see each one of them

Facade Pattern:

• Purpose: The Facade pattern provides a simplified, high-level interface to a complex subsystem or set of classes. It acts as a “facade” to shield clients from the underlying complexities of the system.
• Use Cases: It’s useful when you want to provide a simplified and unified interface to a complex system, making it easier for clients to interact with it. It promotes loose coupling between the client code and the subsystem.

The image below present the pattern using a Class Diagram:

Example of Use: Multimedia Player Facade

Suppose you are building a multimedia player application that can play various types of media, such as audio and video files. The underlying multimedia framework is complex, with different classes and interfaces for handling codecs, rendering, audio output, and video display.

In this example, we could consider implementing a class of name MultimediaPlayerFacade that acts as a simplified interface to the complex multimedia framework. It encapsulates the initialization and usage details of the audio and video players, making it much easier for client code to play multimedia. The client code is simplified and less coupled to the underlying multimedia framework, which can change without affecting the client code.

The Facade pattern here provides a cleaner and more maintainable way to interact with a complex subsystem, shielding the client code from its intricacies.

Adapter Pattern also known as Wrapper Pattern::

• Purpose: The Adapter pattern allows two incompatible interfaces to work together by providing a wrapper around one of them. It acts as a bridge between two interfaces, making them compatible without changing their source code.
• Use Cases: It’s used when you have existing code with interfaces that are not compatible with the interfaces you need to use. The adapter pattern allows you to reuse existing code without modification.

The image below present the pattern using a Class Diagram:

Example of use: Legacy System Integration

Imagine you are working on a modern e-commerce application that needs to integrate with a legacy payment gateway. The legacy payment gateway has an outdated interface that doesn’t match the modern payment service interface your application uses. You can use the Adapter pattern to bridge the gap.

To integrate the legacy payment gateway with your modern payment service, you can create an adapter class. In this way you can use the Legacy Payment Adapter to make payments through the legacy payment gateway using the modern payment service. In this way the adapter acts as a bridge between the modern payment service interface and the legacy payment gateway.

Proxy Pattern:

• Purpose: The Proxy pattern provides a surrogate or placeholder for another object to control access to it. It can be used to add an additional layer of control over an object, such as lazy loading, access control, or caching.
• Use Cases: It’s useful when you want to control access to an object, especially in situations where the creation or access to the object is expensive or where you need to add functionality around object access.

The image below present the pattern using a Class Diagram:

Example of use: Image Loading Proxy

Suppose you are building an image viewer application, and you want to implement a feature that loads and displays high-resolution images from a remote server. However, loading these high-resolution images can be slow and resource-intensive. To improve user experience and optimize resource usage, you can use the Proxy pattern. You can use the ImageProxy to load and display images in your application without loading the high-resolution image until it’s actually needed. Consequently you can delay the creation and loading of resource-intensive objects, improving the performance and resource utilization of your application.

Observer Pattern:

• Purpose: The Observer pattern defines a one-to-many dependency between objects so that when one object changes state, all its dependents (observers) are notified and updated automatically.
• Use Cases: It’s commonly used for implementing distributed event handling systems, where multiple objects need to react to changes in another object’s state. Examples include GUI frameworks where UI elements update when underlying data changes.

The image below present the pattern using a Class Diagram:

Example of use: Weather Monitoring System

Imagine you are building a weather monitoring system that collects weather data from various sensors and notifies multiple display devices when the weather conditions change. In this scenario, you can apply the Observer pattern to implement the system. You could imagine a class of name ConcreteWeatherStation as the subject that collects weather data and notifies its observers (in this case, maybe various display objects) when the data changes. The Observer pattern allows multiple display devices to receive and react to updates without being tightly coupled to the weather station.

Summary of Software Patterns or Design patterns

Software patterns, also known as design patterns, are widely recognized and essential approaches for organizing code and solving recurring design problems in software development. Among these patterns, the Facade pattern simplifies complex subsystems by providing a unified interface, making it easier for clients to interact with intricate systems. The Adapter pattern bridges the gap between incompatible interfaces, allowing different components to work seamlessly together. The Proxy pattern acts as a surrogate for an object, controlling access and adding functionality, which can be valuable for resource optimization and security. Lastly, the Observer pattern facilitates the creation of distributed event handling systems, enabling one object to notify multiple observers about changes, enhancing code modularity and flexibility. These patterns represent just a subset of the many design patterns available, and they serve as valuable tools in the developer’s toolkit for building maintainable, scalable, and efficient software systems.

In the case you would like to learn more I would recommend you to have a look at the following book from “the gang of 4“

It is a classic and several libraries will probably have a copy.

The post What Software Patterns (or Design Patterns) are and an introduction to the most common one appeared first on Francesco Lelli.

• After the initial pain, and maybe a bit of a slow start, your thesis will advance ten times faster and you will be capable to achieve more than you can imagine.
• What you will be learning will not be lost. Many companies use a similar environment (if not the same).
• Many of these resources are free and you will be able to use them for other projects after the end of this academic endeavor.

In other words, you have nothing to lose. All you have to do is to endure a bit of the initial annoyance that is required for a proper warm up of your programming environment. However, the reward is much greater than the initial investment.

In this article, I list only a very few resources and only the ones that are free. In the internet you can find many more.

Programming skills: no matter how much you know, there is always room for knowing more. Most libraries, both public and university, have free subscriptions to courses. For example, the library in my university gives free access to DataCamp to all the students that request it.

If you are not familiar with the platform, it contains a set of courses at all levels and many of them have code examples. As they cover a large range of cases, some of them will be relevant for your thesis. All you have to do is to dig into the list and familiarize with the code that is most promising for the work that you plan to do with your supervisor.

Get a student account in GitHub, it is a free repository that you can use for storing your code. Calming student status will grant you a pro version for free as well as many discounts for products of other companies. In addition, you will also not loose these perks after the graduation – some of them could be useful for you in the future.

Get an account in Kaggle, again, it is a free service that has courses and datasets. They also offer a web based programming environment with the idea that if you will find yourself in need of additional computation, you will use their services. As a general rule, I would recommend to have a local working environment instead of a cloud based like the one of Kaggle. However, a cloud based environment may be useful under certain conditions.

Set up Anaconda (or Eclipse) in your laptop. An Integrated Development Environment is extremely useful when you have to do some professional programming. Anaconda is free, open source and perfect for Python. Eclipse is its counterpart for Java. In the article below you can read about some of the benefits of an IDE. Once you will start using one you will never go back:

This article is a mini-tutorial on how to set up the environment for Anaconda:

Finally, in the article below, you can familiarize with the debug functionality. It is one of the most useful features of an IDE and can really save you a tremendous amount of time:

I would strongly encourage you in enduring the pain of getting familiar with the tools and the resources that I shared with you in this article. In the long run your future self will be extremely thankful.

A working environment is a very personal thing and I can imagine that every supervisor has their own. Consequently, I would encourage you to discuss the details during your first meeting. At the same time, I can imagine that these tools will be, in a way or an other, useful for your future work. In addition, the fact that you will have your working environment ready will allow you to advance conversations that are more specific to your thesis and you will result in a better use of the (limited) time that you will share with your supervisor.

#free #Resources that will #SHARP your #programming #environnement. #Java #pythonprogramming #pythoncode #DataScience #DataAnalytics #data
Share on X

By the way, here you can fine my profiles in GitHub Kaggle and DataCamp:

• https://github.com/Nym77
• https://kaggle.com/francescolelli
• https://www.datacamp.com/profile/flelli
• https://www.freecodecamp.org/francesco-lelli

Are you really committed in improving your programming skills?

Free Code Camp is an open source free course that will guide you in a project based journey towards advanced programming skills. It contains also a session on how to pass a programming oriented job interview.

Introduction to Computer Science from Harvard This is a free edX course from Harvard. You can also get a certificate but this will cost you something. Nevertheless the entire course is free.

Something else:

This article (Free Resources That Will Warm Up Your Programming Environment) is part of the miniseries on how to do a good thesis, you can see the full list of post at the following link:

This article is also part of a miniseries on how to become a better programmer. You can see the full list of posts at the following link:

The post Free Resources That Will Warm Up Your Programming Environment appeared first on Francesco Lelli.

Abstract:
With technology in reach of everyone and the technology sector in ascendance, it is central to investigate the relationship people have with their devices. We use the concept of agency to capture aspects of user’s sense of mastery and control in relation
to their device. This study gives preliminary evidence of the existence of two dimensions of agency for modelling the interaction between humans and smart devices: (i) user agency and (ii) device agency. These constructs emerged from an exploratory factorial analysis conducted on a survey data collected from 587 participants. Mapping the users’ dynamics with their devices into user agency and device agency advances our understanding of how digital technology shapes human cognition and emotion and how
users interact with technology. This approach can assist in designing interfaces that match the beliefs users have regarding their capabilities and the capacities of their devices.

Key words: Agency, Human-Computer Interaction, smart devices, user agency, device agency, exploratory factorial analysis, survey.

we show that agency in human-smart device interactions is a twofold and graded construct, consisting of user agency and device agency. The attributing of agency to themselves and to their device frames how the users are perceiving and leveraging the affordances of the smart device. The attribution of user and device agency can be used as a measure for understanding if the user masters the device’s potentials to the fullest or not. Thus, user agency and device agency can be used as proxies for understanding how users experience their relationships with their devices.

The conceptualization of agency proposed here should be further refined in relation to other existing constructs. We should investigate whether user and device agency act as mediators for other factors of human-device interaction such as anthropomorphism and other concepts mentioned in this article. Furthermore, our exploratory study should be developed further to a point where we can perform confirmatory factor analysis. As the next step, an expert panel will be summoned to review the items used in this study, in preparation for refining the survey before collecting new data for the second set of statistical analyses. Furthermore, we should continue exploring the nuances of agency in different contexts of smart device use, such as work vs. personal.
Brad Pitt as Tyler Durden in Fight Club (1999) states that “the things you own end up owning you”. In the context of smart devices, this is true only if we are unaware of the agency we attribute to our devices and to ourselves. Perhaps the secret of a balanced relationship with our gadgets is in making an aware decision of when and how to be “owned” by the device and when not.

Full article available at this link.

Check out the presentation:

Your help in sharing the idea is very welcome!

Agency in Human-Smart Device Relationships: An Exploratory Study #HCI #IoT #smarthome #homeautomation #survey #softwaredevelopment #softwareengineering
Share on X

Cite this paper as:

Toivonen, Heidi and Lelli, Francesco, “Agency in Human-Smart Device Relationship: an Exploratory Study” (2021). PACIS 2021 Proceedings. 145. https://aisel.aisnet.org/pacis2021/145

Check out the Related Dataset: Lelli, Francesco; Toivonen, Heidi, 2021, “A Survey for investigating human and smart devices relationships“,  https://doi.org/10.34894/TRAONY, DataverseNL, V1

• Full list of Articles
• Full list of Conference Publications

The post Agency in Human-Smart Device Relationships: An Exploratory Study appeared first on Francesco Lelli.

Abstract:
The growing synergy between Web Services and Grid or cloud based technologies is enabling profound, dynamic interactions between applications dispersed in geographic, institutional, and conceptual space. Such deep interoperability requires the simplicity, robustness, and extensibility for which XML has been conceived, making it a natural lingua franca for the network. Along with these advantages, there is a degree of inefficiency that may limit the applicability of XML.
In this paper, we investigate the limitations of XML for high-performance and high-interactive distributed computing. Our experimental results clearly show that focusing on parsers, that are routinely used for desterilize XML messages exchanged in these system, we can improve the performance of a generic the end to end web services based solution. Then we present a new parser, the Cache Parser, which uses a cache to reduce the parsing time by reusing information related to previously parsed documents/messages similar to the one under examination. Finally, we will show how our fast parser can improve the global throughput of any application based on Web or Grid or Cloud Services, or also RPC calls in general.

Key words: Web Service, Cloud Services, 3 tier architecture, SOA, RPC, Service Oriented Architecture

The may Web Services fully solve the “global enterprise integration” problem, but the proposed solution seems to exhibit a poor performance, and we believe that this could pose serious limitations on their actual applicability, as the number of commercial users will increase.
As shown in paragraph 2 we also believe that one of the limitations in using a full WS approach for implementing complex and highly interactive systems, comes from the large de-marshalling costs incurred on the receiver sides.
To solve this problem, we have designed a new parser: the Cache Parser. It is able to “well and quickly” retrieve information from XML documents, using previous knowledge about the document syntactic tree. In particular, our Cache Parser, which is used to de-marshal XML messages on the receiver side:

• Uses a checksum to detect if a new document is “well formatted”, and to know if it shares the syntactic tree with an already parsed one.
• Takes advantage of this XML-Document syntactic tree stored in a cache.
• It is based on a strict collaboration between sender and receiver.
• Consistently reduces the receiver parse time, without increasing the sender document creation time.

This algorithm is 25 time faster than a pull parser and if used in a WS scenario it can allow a 1.54 performance improvement factor in term of request handled per second. Finally it can be applied in any scenario where the client and the server decide to cooperate.

Full article available at this link.

Your help in sharing the idea is very welcome!

Improving the #performance of XML based technologies by caching and reusing #Information. #Webseries #RealTime #CloudComputing #API #APIs #programming #softwareengineering
Share on X

Cite this paper as:

F. Lelli, G. Maron, and S. Orlando. Improving the Performance of XML Based Technologies by Caching and Reusing Information.. IEEE International Conference on Web Services (ICWS), Chicago, September 2006.

• Full list of Articles
• Full list of Journal Publications

The post Improving the performance of XML based technologies by caching and reusing information appeared first on Francesco Lelli.

Is it possible to achieve a Client Side Estimation of a Remote Service Execution?

Abstract:
Many use cases, concerning the monitoring and controlling of real physical instruments, demand deep interaction between users and services that virtualize the access to such instruments/devices. In addition, in order to realize high interoperable solutions, SOA-based Web/Grid Service technologies must be adopted. When the access to one of these services is performed via internet using a Web Service call, the remote invocation time becomes critical in order to understand if an instrument can be controlled properly, or the delays introduced by the wire and the serialization/ deserialization process are unacceptable. This paper thus presents methodologies and algorithms, based on a 2k factorial analysis
and a Gaussian Majorization of previous service execution times, which enables the estimation of a generic remote method execution time. Furthermore it suggests three different software architectures, where the developed algorithms and methodology could be integrated in order to automatically profile the end-to-end service. It is worth noting that our proposals are validated using suitable benchmarks and extensive tests coming out from a real (not simulated) environment. In addition, the outcome of this paper have been used in the realization of a service for remote control, monitor, and manage of a pool of instruments/devices.

Key words: Web Service, Quality of Service, QoS, Grid, Cloud Services, Response Time

In this paper you will understand the state of the art on Quality of Service in today digital services with particular attention to Web Services. In this scenario, we proposes a set of solutions that enable a remote service invocation time to be predicted in a general scenario. The contribution of this paper can be divided in three different parts:

• Section 3 formalizes the problem while Sections 5 and 5.1 validate this formalization by providing a dataset for web service QoS study. In particular, the dataset consists of 2304000 samples (of 9 significant values each) organized in 2304 different tests.
• In the second part of this paper (Section 4, 6, and 7) we analyze the collected dataset in a more exhaustive way. Two variants of a methodology that utilizes a Gaussian approximation of the dataset distributions, in combination with a regression model of the key factors that influence the average and the standard deviation, have been developed in Section 4.
• Then, in Section 6 our estimators are validated with experimental results in several scenarios. In the last part of this paper (Section 7), we propose three different software architectures that can utilize the developed methodologies and algorithms. It is worth noting that the presented solutions have been already adopted in a Grid context during the design and implementation of our IE

We have also experienced that in case of server overload, the number of deadline misses increases. This suggests a possible approach for an automatic organization of the clients that balances the servers’ load, and that could be exploited to solve the use cases mentioned in the introduction of this paper. If the number of deadline misses is greater than the expected
ones, the server machine is probably overloaded. So clients could/should decide to use a different machine, in which an identical copy of the invoked service is deployed.

Full article available at this link.

Your help in sharing the idea is very welcome!

Client Side Estimation of a Remote Service Execution. #Webseries #RealTime (sort of) #CloudComputing #API #APIs #programming #SoftwareEngineering
Share on X

Cite this paper as:

F. Lelli, G. Maron and S. Orlando. Client Side Estimation of a Remote Service Execution, 15th Annual Meeting of the IEEE International Symposium on Modelling, Analysis, and Simulation of Computer and Telecommunication Systems (MASCOTS), Istanbul, Turkey October 2007

• Full list of Articles
• Full list of Journal Publications

The post Client Side Estimation of a Remote Service Execution appeared first on Francesco Lelli.

Abstract:
Software engineering is a complex sociotechnical activity, due to the need for discussing and sharing knowledge among team members. This has raised the need for effective ways of sharing ideas, knowledge, and artifacts among groups and their members. The social aspect of software engineering process also demands computer support to facilitate the development by means of collaborative tools, applications and environments.
In this paper, we present a survey of relevant works from psychology, mathematics and computer science studies. The combination of these fields provides the required infrastructure for engineering social and collaborative applications as well as the software engineering process. We also discuss possible solutions for the encountered shortcomings, and how they can improve software development

Key words: Social Software Engineering, Psychology, Collaborative tools, mathematical techniques.

In this paper you will see:

• a set of relevant works from psychological and social areas that could be integrated in modern software development.
• relevant works in building collaborative and social tools
• a set of references on mathematical techniques that have been or could be used in order to validate ideas around social software engineering.

We addressed the idea of Social Software Engineering by providing a survey of contributions in related areas. We identified and discussed two main subcategories: on the one hand the need to integrate results from social and psychological sciences in the software lifecycle; on the other hand, we outlined the need for engineering social networking services and collaborative tools. As a matter of fact, these applications have been developed independently but they share many use cases. Therefore, by approaching the problem in a systematic way we can try to formalize and improve these classes of applications.
Finally we presented a set of mathematical techniques that have been used for experimental validation of scientific contributions: these techniques may be used as basic blocks for understanding the ideas proposed for social software engineering

Full article available at the following link:

A Survey of Social Software Engineering https://ieeexplore.ieee.org/document/4686304

PDF also available at this link.

Your help in sharing the idea is very welcome!

Writing #Software is a social endeavor: A #survey of #Social #SoftwareEngineering
Share on X

Cite this paper as:

N. Ahmadi, M. Jazayeri, F. Lelli, and S. Nesic. A Survey of Social Software Engineering In the First International Workshop on Social Software Engineering and Applications, Vol. 1, No.1 pp. 1-12, L’Aquila, Italy, Sep. 2008.

Authors in alphabetical order

• Full list of Articles
• Full list of Journal Publications

The post A Survey of Social Software Engineering appeared first on Francesco Lelli.

Service Encapsulation is often used to hide the internal representation, or state, of an object from the outside. In this way, we can present to the outside world a cleaner, simpler, and more coherent view of the internal systems. Many services which were not initially planned for a Service Oriented Architecture (SOA) may get encapsulated or become a part of a SOA in this way.

In the example of ACME Social and University of Nowhere, both the parties agreed on exchanging information in order to improve the existing geolocation service of ACME Social. In particular, ACME Social would like to receive the following information from the University of Nowhere:

• Retrieve a list of unique IDs of the students
• Retrieve the email addresse(s) of each student
• Get the class that the student is supposed to follow
• Retrieving the exact coordinates of the location of a given student according to the University of Nowhere.

Service Encapsulation: Can we design it as a stateless service?

Probably yes, even though students and their respective locations will change. From the point of view of the methods, we can expect that their behavior will not change over time. A possible UML diagram that describes the interface of the service could be as follows:

The class represents all the functionalities requested by ACME Social in 4 methods. It does not have attributes and this approach will keep the design simple. IDs, emails, as well as geocoordinates will be shared as Strings in order to use one of the basic types of a service.

In the case we will decide to implement a WS-I compliant service, we can assume that the calls of the methods can fail and may trigger exceptions on the service consumer’s side.

What about the concerns of ACME Social and the documentation of the service?

As the service represents the entry point of the systems of the university of Nowhere, we need to carefully balance the complexity of the interface that we need to design. On the one hand, it must be able to mask all the idiosyncrasies of the IT of the university in order to facilitate its consumption by ACME Social. On the other hand it must be able to deliver everything that is needed and agreed. The figure below shows how this interface sits at the intersection points of two different worlds with different needs and goals:

ACME Social, i.e. the client of the service needs a clear answer to the following questions:

• What does the service do? Answering to this question will require a proper documentation of the methods. The name may be intuitive, but some of its behavior may not. Therefore, it needs to be carefully documented.
• How can we use the service? The best way to answer this question is with an example of use. ACME social may use different languages so the example(s) need to be written in Java and Python (for example) and the code must be well documented (see these best practices).
• Where can we locate the service? The URL of the service, together with the way to get the authorization of use, should be part of the documentation. In addition, the service should be part of an UDDI registry as well.

ACME Social is not at all interested in:

• How to represent internally the request received from ACME social
• How to implement the service
• Where to host the server needed for running the service
• How to publish the service in the Internet
• How to keep it running

These aspects are of fundamental importance for the University of Nowhere. However, these concerns should not be shared with the consumers of the service.

A #service Encapsulation example using a location service. #servicedesign #programming
Share on X

The post A Service Encapsulation Example Using a Location Service appeared first on Francesco Lelli.

There is more to object oriented programming. If you want to be able to write code that you can re-use 2 weeks after, you want to put attention to how to write good quality code. This activity takes time, but if you want to be able to look back at what you have done (and you want it!) you have to pay the price.

Next, consider the importance of commenting your code and the proper way to do it. This is a fundamental activity. However, more commenting is not necessarily better then less commenting.

This second set of talks digs deeper into the profession of software engineer/ programmer and promotes an attitude that fosters collaboration and ethics.

One of the problems that the industry is facing is that in the past 50 years, the number of programmers doubled every 5 years. Therefore, the industry remains young and the experienced coders face the trouble of passing their knowledge to the new generation. In one line: act professional!

Test driven development is a software development process that relies on the repetition of a very short development cycle: Requirements are turned into very specific test cases, then the code is improved so that the tests pass. This is opposed to software development that allows code to be added that is not proven to meet requirements. This, together with making correct estimates and saying no is the right attitude for delivering successful results.

Software architecture refers to the fundamental structures of a software system and the discipline of creating such structures and systems. Each structure comprises software elements, relations among them, and properties of both elements and relations. In the video below, you will learn the fundamentals of software architecture, its rules, the value of discipline in the production of quality code, and the responsibility of disseminating the need to implement these good practices in the community of programmers.

Challenges in software and software management include the problem of adjusting software production time to delivery times. In other words, we are talking about the divergence between the needs of the client, the commercial commitments, and the needs of the programmer to produce quality software. Software project management is comprised of a number of activities, which contain planning of project, deciding scope of software product, estimation of cost in various terms, scheduling of tasks and events, and resource management. This last talk is about some of these challenges:

In summary, quoting from Uncle Bob:

Even bad code can function. But if code isn’t clean, it can bring a development organization to its knees. Every year, countless hours and significant resources are lost because of poorly written code. But it doesn’t have to be that way

#HowTo write clean #code by Uncle Bob ( Robert Cecil Martin ) #softwaredevelopment #CodeNewbie #HowtoPerfect
Share on X

How to write clean code? In case you would like to know more, here you can find a link to his book:

Clean-Code-Handbook: https://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882

The post How to write clean code by Uncle Bob (Robert Cecil Martin) appeared first on Francesco Lelli.