Giter Site home page Giter Site logo

til's Introduction

Today I Learned - The knowledge hub

These are what we've learned everyday, organized by Github Issue.

Dwarves never stop learning, and this is the space for our team members research/discuss about hard things. Hard things are? Just not easy things. We believe continous learning and getting out of comfort zone are the way to be the best individual.

We also do seminar every 2 weeks. We share about everything: technical stuffs, business knowledge and sometimes life growth hacking skills.

Dwarves never stop mining, and this is a chance for our team members research and share what they've digged. They can find anything they want.

Example: 21-06-2017_The-miracle-webpack.

  • PDF files follow 4:3 or 16:9 standard.

If you are interested in this repo, please follow #til and support us.

License

Copyright @ Dwarves Foundation

til's People

Contributors

huynguyenh avatar runivn avatar tieubao avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar

Forkers

paulgeisler

til's Issues

Tail recursion là gì? Tại sao nên áp dụng tail recursion khi dùng đệ quy.

Bắt đầu với functional programming, chúng ta phải làm quen và nắm vững recursive, thay vì for, while sử dụng phổ biếng trong OOP.
Chính vì thế việc tối ưu bộ nhớ khi sử dụng đệ quy là điểm cần lưu ý. Vậy Tail recursion là gì, nó giúp thế nào trong việc tối ưu bộ nhớ?

Cho ví dụ bài toán tính giai thừa sử dụng đệ quy sử dụng ngôn ngữ Elixir

defmodule Math do
  defp factorial(0) do
    1
  end
  defp factorial(n) when n > 0 do
    n * factorial(n-1)
  end
end

Các bước gọi hàm
Math.factorial(3)
=> Phân tích ra

factorial(3)
3 * factorial(3-1)
3 * factorial(2 * factorial(2-1))
3 * factorial(2 * factorial(1 * factorial(1-1)))
3 * factorial(2 * factorial(1 * factorial(0)))
3 * (2 * (1 * 1))

Đối với đệ quy (body recursion), mỗi bước function gọi lại chính nó thì 1 lượng bộ nhớ lại được cấp phát thêm cho function mới và giữ trong RAM cho đến khi tất cả các sub function được tính toán xong, gộp kết quả lại, do đó bộ nhớ sẽ tăng lên rất nhanh nếu hàm đệ quy của chúng ta gọi nhiều lần.
ví dụ gọi hàm giai thừa cho 10.000.000 ~ 5.6GB bộ nhớ dùng cho hàm tính toán giai thừa này.

screen shot 2018-09-10 at 14 59 15

Improve hàm đệ quy trên, thay vì chờ kết quả của các sub function, ta lưu giữ kết quả tính toán qua từng bước gọi. Thay vì hold các function(multiple heavyweight) ta chỉ hold kết quả tính toán và truyền qua từng bước(one lightweight object).

defmodule MathWithTailRecusive do
  def factorial(n), do: factorial_of(n, 1)
  defp factorial_of(0, acc) do
    acc
  end
  defp factorial_of(n, acc) when n > 0 do
    factorial_of(n-1, n * acc)
  end

end

Các bước gọi hàm
MathWithTailRecusive.factorial(3)
=> Phân tích ra

factorial (3)
factorial_of (2, 3 * 1)
factorial_of (1, 3 * 2)
factorial_of (0, 6)
6

So sánh bộ nhớ sử dụng khi tính toán giai thừa 10.000.000 bằng tail recursion , chỉ 42MB so với 5.6GB của body recursion, một sự khác biệt cực lớn.
screen shot 2018-09-10 at 15 02 02

Kết luận:

  • Body Recursive:
    +Nhược điểm: tốn bộ nhớ, cần lưu ý khi khi hàm của chúng ta lặp nhiều lần
    +Ưu điểm: dễ đọc và nắm bắt logic có thể dùng cho các hàm giai thừa mà chúng ta đoán biết số bước gọi đệ quy nhỏ.
    -Tail Recursive:
    +Nhược điểm: Khó viết đối với các bài toán phức tạp, khó nắm bắt logic khi đọc code.
    +Ưu điểm: tối ưu bộ nhớ.

Tham khảo thêm tại:
https://stackoverflow.com/questions/33923/what-is-tail-recursion

"Shortcuts" - Hướng đi mới của Apple trong việc tạo ứng dụng di động.

Bắt đầu từ iOS 12, Apple introduce ứng dụng "Shortcuts".
https://itunes.apple.com/us/app/shortcuts/id915249334?mt=8&ign-mpt=uo%3D2

Shortcuts là ứng dụng cho phép user có thể define một workflow và tạo Shortcut nhanh để run Workflow đó.
Ví dụ chúng ta có thể quick look các bài viết mới nhất tại trang Tinhte qua RSS feed ngay trên màn hình Widget, lướt nhanh SubRedit, Translate đoạn text trong Clipboard sang tiếng Việt, Upload 1 image và trả về url trong clipboard, Scan QR code, change setting của device khi đến 1 địa điểm, tự động lấy báo cáo thời tiết, tin tức vào buổi sáng, tích hợp với Home kit mở, tắt đèn...

Không chỉ cung cấp các action sẵn có, developer chúng ta có thể phát triển các "action" dùng để tích hợp với các action sẵn có của Apple và bên thứ 3.

Demo:

  1. Cài đặt Ứng dụng Imgur trên Appstore, đây là ứng dụng cho phép upload ảnh dùng để nhúng vào các forum hay chia sẻ, ứng dụng này đã phát triển "Shortcut action" cho phép chúng ta Input đầu vào là 1 image -> upload -> image url.

  2. Tạo Siri shortcut cho phép chọn 1 ảnh trong Photo Album và trả về 1 URL để nhúng diễn đàn:

  • Mở ứng dụng "Shortcuts" và chọn "Create shortcut"
    img_6080
    Chọn các action
    Select Photos - Upload to Imgur - Copy to Clipboard

img_6081
Ở đây Select photo là input, ta có thể chọn các input từ các nguồn khác nhau vd như Album, Take From camera, từ 1 ứng dụng chỉnh sửa khác, workflow khác...

Nhấn "Done để lưu lại"

Chúng ta có thể access Shortcut này tại màn hình khóa.
img_6082

Chọn Image source
img_e7315a892f45-1

Uploading
img_6083

test thử bằng các parse vào Safari

img_7953037c4fa5-1

Một số Short khác mới vọc tối qua:
Translate:
img_6086
Tinh Tế
img_6087 2

Browser Sub Reddit
img_6088

Có rất nhiều shortcuts mà chúng ta có thể tham khảo, cài đặt hoặc tự tạo cho mình, có thể tham khảo tại sub reddit r/shortcuts

Về phía developer chúng ta, chúng ta có thể phát triển các action để tích hợp với Siri. Ví dụ ứng dụng Findfriend có thể tạo shortcut để lấy list thành viên group, bấm vào thành viên có thể show tiếp action Call, show location, send message...
Apple đã mở ra 1 hướng đi mới trong lập trình di động, trong đó các ứng dụng có thể tương tác mạnh mẽ với nhau, user có thể define bất chuỗi workflow hay automation mà họ muốn, làm cho chiếc điện thoại hữu ích và đa năng hơn rất nhiều.

Technical Debt

https://ebaytech.berlin/a-city-of-technical-debt-58568747b12

Most engineers who work on large projects will have noticed that the time you need to accomplish anything in a large codebase is incredibly high compared to the same task performed in a small project.
There are a number of potential reasons for slow velocity, but I think technical debt is the most underestimated one.
It’s safe to say that tech debt is the black hole of engineering time and a huge source of developers’ unhappiness. Let’s dive deeper into this phenomenon and define some of its aspects, but more importantly — define what can be done about it.
What is technical debt?
Technical debt (also known as design debt or code debt) is a concept in software development that reflects the implied cost of additional rework caused by choosing an easy solution now instead of using a better approach that would take longer.
More on Wikipedia
Is it always bad?
There is only one good reason for keeping technical debt — when a codebase doesn’t need maintenance. (That may be the case for one-off projects that are completed and never touched again, or legacy projects that are unlikely to be revived or updated.)
In all other cases, debt is tragic for all participants and needs to be taken seriously. Legacy code will have a huge impact on the development of further features, bugfixing, developers’ happiness and in the worst case scenario it can lead to a full development stop and a major rewrite. This happened already to many big companies like eBay and many others didn’t survive it.
Let me introduce Sally
Sally is an engineer working in a team as web frontend specialist. Her team has mobile developers, designers, backend developers and a product manager. Her team is one of many other teams, focusing on one particular feature in a big product. Every few weeks she discusses features and improvements and agrees to complete them.
Sometimes, during the sprint, she finds technical limitations, specific to the web platform she works on, where the feature design did not consider them during the design phase. Sometimes she recognizes a UX mistake that crept in during the design phase, which only becomes obvious once you see how the app works in real life.
Sometimes there’s a question that needs to be answered by the colleague who wrote the code, because the code doesn’t explain why it does what it does and the colleague is on vacation.
This time though is different: She discovered that in order to implement the feature properly in the way it is designed, she needs to refactor a number of modules used by other features. Sally is in trouble. She already committed to accomplishing the feature in two weeks and one week is already gone.
Sally knows her manager doesn’t have time to understand the technical side of the problem since he operates on a different level of abstraction. She feels obligated to find a solution that doesn’t require additional weeks of work since refactoring other features is not part of her current sprint and the product manager cannot really value something he doesn’t touch directly. He cares much more about getting the feature implemented on time as estimated.
So what can Sally do? She finds a workaround to implement a feature. She does it in a way that is neither clear nor good. She knows this will clearly create a headache for her co-workers, so she creates a ticket to fix this technical debt later. During a code review, her colleagues understand the problem, since Sally said this is a very urgent feature and she needs to have it done tomorrow — otherwise her product manager will be very unhappy. Her understanding colleagues approve the pull request and the code gets merged.
Sally continues to increase technical debt while product management fails to see the importance of reducing technical debt, since management doesn’t have to deal with code and engineers neglect to explain the problems due to their complexity.

https://www.researchgate.net/publication/310461939
Why is it important to reduce the debt?

  1. Velocity decrease
    Many people think of technical debt as a single big problem — which it sometimes is. Most of the time though, it’s not a single problem, it’s hundreds of small problems.
    Readability and clarity of code have a very strong impact on development speed since they make it easier to understand what code is supposed to do — the intent. For this reason, it is harder to anticipate the side effects unclear code may create and it is harder to change and test.
    Indeed, the ratio of time spent reading versus writing is well over 10 to 1. We are constantly reading old code as part of the effort to write new code. …[Therefore,] making it easy to read makes it easier to write.
    — Robert C. Martin, Clean Code: A Handbook of Agile Software Craftsmanship
  2. Bugs increase
    The ease of understanding the code usually correlates with the ease of fixing bugs. If you are not careful with this, you will generate huge amount of bugs even before releasing the feature.
    The cleaner the code is, the easier it is to avoid adding bugs.
    Tests are very important to have, but they will never cover everything, even if the test coverage reports 100%. The code in an actively maintained project is a moving target, it changes all the time and so do the use cases for the code. Public functions may be used more and more over time, which adds more potential use cases that were not anticipated by the initial author.
  3. Dirt attracts dirt
    The more debt there is in the code base, the less desire people have to fix it — and the more debt will be created. Imagine walking on a perfectly clean street and you just finished your last cigarette and are looking to drop the stub. Would you do it on a nice, clean street? Probably not. Now imagine the same scenario, but the street is dirty, trash is everywhere — now it’s easy, right? This is also known as the “broken windows theory”. The same goes for the codebase. Keep it clean, or you’ll eventually find yourself sinking in tech debt.
  4. Always put people first
    We say so often “put people first” when you build an organization or society, but what would that mean in software engineering?
    I think it means we need to understand what makes engineers unhappy about the code quality. There are many factors for sure, but burning brain cycles to figure out how the code works (because it’s hard to understand or poorly structured) is one of the primary causes. Having tests is also quite important in a large organization, because they help people understand the intent and help to ensure previous use cases don’t break when code is changed.

https://neo4j.com/blog/other-graph-database-technologies/
Code is a graph database
We could look at the codebase like at a graph database. Each dot represents a an isolated system and has a different purpose, performance characteristics, series of dependencies and dependants. Each time we change it, we always need to think of whether any of these characteristics also changed in a way that would require refactoring.
When you’re thinking about adding a component, for example, you need to check whether an existing component could be used, since it would otherwise create a needless duplication.
In another case, you might think you could use an existing component which looks very similar to what you need, but the use case for which it was designed is different — its characteristics have been optimized for a different purpose. In this case, you’d be breaking the separation of concerns, which may lead to numerous other issues. For example, if you need to make a change in that component, you will be adapting it for a second use case and by doing so you will make it hard to maintain.
Another consideration is performance. Something that is built to run once is usually designed differently than something that is written to be run millions of times in a fraction of second.
It’s very hard work to keep this graph clean and correct. It’s a constant challenge that requires an investment of time and smart minds. The bigger the graph, the more it takes to keep it clean and functional.
Code is a dialog
Source code is not just a dialog with a computer, it’s also a dialog with a colleague or your future self. If you write code that’s very clever, you may be asking the next reader to put a lot of brain cycles into understanding it. If you write code that doesn’t do what it says it does, you send the reader through a labyrinth of thoughts trying to justify it. It is important to invest enough time and make code easy to read because the next reader will need much more time to understand it than the author — since the author already spent the time thinking about it while implementing it.
Every time you save your time at a cost of code quality, you take even more time from the next person who needs to maintain it.
Why is tech debt so hard to get rid of?
There are many reasons obviously, but if I had to name just 3, it would be those:
Deadlines
Deadlines are the most popular reason for not doing something right. Quality costs time, everyone knows that. Things left for later are usually not done at all until it hurts. Even the work of putting off dozens of things for later is actually a lot of work since you need to carefully document what needs to be done later. Also don’t confuse external deadlines with your own promises, which are just estimates!
Processes
When processes are optimized for and encourage new features only, every person on the team (even engineers) will start seeing this as the most important thing — even if the software is maintained by many people and technical debt is at least as important. Placing emphasis that way makes everyone question the time spent on anything but new features. Developers shouldn’t need to put in extra effort to get the time to do the right thing.
Values
Without a culture that celebrates the actual quality of engineering work (not just the parts that are visible to the user), engineers can end up with a “quick and dirty” mindset. Why would they do otherwise? Give them a reason. Find ways to analyze quality, track technical debt and the quality of architectural decisions to make them visible and celebrate them!
What can we do?
Here are a few ideas on how to improve and avoid getting mired in debt:
Make sure time for learning, pair programming, experimenting, teaching and refactoring is explicitly defined and considered when you estimate. These things can easily take 50% of your time budget.
Create a culture where bad technical choices are not equal to bad engineers. It is often the complexity and time pressure that creates bad decisions. Often enough, good choices can be only made during refactoring.
Make technical debt visible for everyone. When you write a TODO in code:
– Always create a ticket in the issue tracker.
– Add this ticket number to the TODO item in the code.
– Add the “tech-debt” label to the ticket.
Communicate clearly what solving the debt will bring, but even more clearly what problems will be created if the issue is not fixed now.
Make the complexity of debt visible. Either use story points or make small, homogenous subtasks so that effort can be estimated by counting them.
Make a developer-friendly codebase and reduction of technical debt part of the product’s success metrics. Celebrate the quality of inner workings.
Software is hard. Engineers have to deal with huge levels of complexity and naturally sometimes they fail. My role as an architect requires me to think critically and my ultimate goal is to evangelize technical quality in a way that leads to a reduction of maintenance cost over the long term.
I would like to encourage engineers to always think about the people who need to work with their code. Put them first, not yourself, because engineering is a team effort.
Also, I encourage managers to be sensitive towards the problems engineers sometimes fail to explain well, to create a communication culture where delays and plan changes due to discovered difficulties are normal.
If we make sure code quality and architecture is part of the overall product success story, everything will naturally begin to work better.

Custom title and summary only on preference

When using custom preference, if you want to change only title and summary textview attributes, you can override layout preference xml and keep widget layout as the same as original.

Here is the custom xml layout:

<LinearLayout
    xmlns:android="http://schemas.android.com/apk/res/android"
    android:layout_width="match_parent"
    android:layout_height="wrap_content"
    android:gravity="center_vertical"
    android:paddingBottom="@dimen/activity_vertical_margin"
    android:paddingLeft="8dp"
    android:paddingRight="8dp"
    android:paddingTop="@dimen/activity_vertical_margin">

    <LinearLayout
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:layout_weight="1"
        android:orientation="vertical">

        <TextView
            android:id="@+android:id/title"
            android:layout_width="wrap_content"
            android:layout_height="wrap_content"
            android:textAppearance="?android:attr/textAppearanceMedium"
            android:textColor="@color/colorBlack"/>

        <TextView
            android:id="@+android:id/summary"
            android:layout_width="wrap_content"
            android:layout_height="wrap_content"
            android:textAppearance="?android:attr/textAppearanceSmall"/>

    </LinearLayout>

    <!-- Preference should place its actual preference widget here. -->
    <LinearLayout
        android:id="@+android:id/widget_frame"
        android:layout_width="wrap_content"
        android:layout_height="match_parent"
        android:gravity="center_vertical"
        android:orientation="vertical"/>

</LinearLayout>

Spotify Engineering Culture

Spotify Engineering Culture part 1

Autonomy and trust over control

The core principle that binds and drives the Spotify engineering culture is autonomy. Autonomy is all about empowerment and freedom of choice

So, before anyone organization wants to get started, it is essential that the organization identifies a definite objective; what they want to achieve, whether the team has access to all the requisite information to make critical decisions and choose whatever helps them reach that purpose

Autonomy without alignment is futile

any imbalance between the two dimensions, autonomy and alignment, eventually introduces some rate of failure at scale. Though autonomy focusses on the freedom to act independently, to achieve success, the autonomous team need to align with the broader objectives of the organization

Innovation over predictability

values innovation over predictability focussing on experimentation and delivering value. For successful implementation, an organization must review existing practices and be prepared to re-engineer or do away with anything that stifles innovation

Failure recovery over failure avoidance

firmly rooted in the belief that "whoever learns the fastest wins." Their acceptance of failures as a learning opportunity and validation of their learnings reflects that belief. Organizations that are risk averse and goes all out to avoid failure will not be able to achieve any tangible benefits

Spotify Engineering Culture part 2

You have to think for yourself and face your difficulties instead of trying to borrow wisdom


Alignment enables Autonomy

The best software engineer

My friend asked me: How do you know a best software engineer from an average one? Following is my personal opinion:

The best software engineer is very careful when writing code by focusing on the quality not the quantity. The average software engineers like to code, they seem to stay in front of the computer most of the time to generate a lot of code but their programs may or may not work so they have to fix them over and over. This “code and fix” wastes lot of efforts and never achieve the quality as expected by the customers. Good code is done by software engineers that are disciplined, they know how long each problem should take, and carefully planning their approaches to make sure that they complete their task accordingly. As a manager, I have seen both types of software engineer, when I told them “I need this task completed by Friday” then by Friday, someone come and let me know that they have tested their code and it is ready for integration testing. With these people I can feel that there will be very little, if any, defects found by the testing team. However, there are people that told me “I am still coding but it will be done late Friday or early Monday” then with them, I can be sure that they may have skipped some tests to meet the dateline and most of the time their codes are full of defects. Why? Because a good software engineer know how long it takes and plan the work carefully and will let me know whether they can make the dateline or not when an average software engineer would rather code first then ask question later.

For every problem there are many ways to solve it but the best software engineer would try to understand the problem first before doing anything. By having understood the problem, he will be carefully thinking on how to solve it and discuss it with their team on the best solution. He knows that there are many options and what he proposes may not be the best so he is seeking advises from others and come up with a logical and better approach. By look at the problem, figure out what the outcome needs to be, he will figure how much time he need to solve it, and what kind of quality being expected before he even starts to work on the solution. On the contrary, average software engineers would immediately start to code first without much thinking then fixing it if it does not meet the requirements. This type of “code and fix “then “fix then code” will never create quality software because the more they fix, the more defects they will injected into the solution.

Best software engineers always share things with the team and learn from each others. They know that by sharing, they learn more so when they learn new things, new technologies they will discuss with the team about what works and what do not work so people can avoid making mistakes. They are better by making other better .They always seek advises from senior people because these people have experiences, been through many projects and know by instinct to make the right decision. Average software engineers may be very good in what they do but they like to be a hero, to be recognized by others so they do not like to share and keep information to themselves, in this case they are losing their value because software work is teamwork and a team that have too many heroes eventually will have no hero at all because everybody will fail. Even if they are good and could finish their works on time but if the team did not then the project still fail. When a project fail, it does not matter who is finishing the work first and who can do good work it is a team’s failure because the overall goal can not be achieved.

One of the skills that can bring everything in the project together is organization skill. Average software engineers are very good in technical but if they are not organized, they will not be able to get things done and eventually will be overwhelmed by the project pressure. Best software engineers always keep a project plan with detailed daily tasks and are able to prioritize them accordingly. They know their daily outlook of meetings and tasks and keep up to date everything that they must achieve on that day so things will not get postponed into the next day. They keep track of all their works and can instantly pull up projects, meeting reports, and other details when asked. By getting things done each day they know their schedules and expectations and be able to adjust them to meet project’s goals. On the contrary, average software engineers do not think far ahead but only work according to what the manager tell them and what the schedule dictated each day. When things change, they do not know what to prioritize and have no plan to accomplish them but rely on the project manager to assign them works accordingly. Best software engineers not only thinking about the project goals, but also visualizes it and understands how to accomplish it because they can see exactly what they must be doing each day, each week, each month to meet the expectation.

Best software engineers will constantly improving their skills. They always seeking new knowledge and usually do not wait for managers to ask them to take additional training. They learn new things on their own because they want to be the best. They find new training classes that they want to go and ask managers for permission to attend so they can learn some thing new and contribute more to the organization. Average software engineers do not like to learn new things much because they believe that they already graduated from universities, have degrees and know “enough to do their jobs”. They are content of what they know but they do not understand the fact that technology always changes so after few working years they will worry about their career because they may not have the skills that the company need and may not be able to keep the jobs. Software is a very dynamic field and if people do not keep up with the technology change, they may be eliminated.

There are many average software engineers in the industry today but there are very few “best software engineers”. The reason is simple: today very few schools would teach communication and teamwork in the software engineer program. Average software engineers may be good in technical but poorly in communication and teamwork. They do not know how to discuss things over emails, participate in SCRUM meetings, share “Best practices: in a technical reviews, present to the customer about a technical solution and promote hundreds people about the software product in a marketing campaign. The ability to communicate clearly and effectively is very critical to all software engineers. The better your communication skill, the farther you will go because best software engineers spend most of the time in communication, explaining the company’s goal, solicit customer’s business, solving problems, giving directions, motivating other workers etc.

Of course some of you may think that I am so idealistic about software engineering but I have been in this software business for over 35 years and have seen a lot of good software engineers as well as average engineers. I can confidently stated that the better you can improve your software skill, make yourself proactive in learning, sharing, improving then the better chance you will become one of the best software engineer that you have ever imagined. If you choose to think of yourself as “good enough”, and have nothing more to learn, you will always staying where you are then over time, you will start to worry because if you are not moving forward, you are not even standing still but actually you are moving backward because the world is moving fast forward.

As a software engineer and a professor, my last advice to you is you must have passion on what you do. Without passion, you will not be a great software engineer, or great at anything. Lack of passion is the number one reason so many software engineer never become good for what they do and it is also the number one reason many people do not succeed in their career. By follow these advises, you may get the position you want, improve what you have been waiting for, and you will be happier with your career because the software industry always demand the best engineer and it is great to know that you are one of them.


http://science-technology.vn/?p=3246

Software quality assurance usually come from Technical Lead group, who are experienced developers

Some of you ask me about the difference between Software Quality Assurance (SQA), Software Quality Control (SQC) and Software Testing. Basically, SQA focuses on issues related to the process that create the software product. SQC focuses on the issues related to the software products. Testing is the method of SQC to make sure that the product works as expected.

Sometime, people confuse SQA with Test and consider SQA as a testing organization which is NOT correct. The IEEE Standard. 12207-2008 stated that “The purpose of the Software Quality Assurance (SQA) is to provide assurance that work products and processes are complying with predefined plans.” The standard also stated that the SQA process should be coordinated with the related project activities such as verification, validation, review and audit processes to identify non-conformances. It means that SQA assures that products and processes comply with the project plans and organization’s standard. The standard requires SQA to assures that these processes are documented, followed and consistent with the company’s policies. The products are fully satisfy the requirements and are acceptable to the users. For example: SQA reviews project requirements, architect and designs to ensure that they are documented accordingly and project team members are following the organization’s process to develop software. SQC and Testing executes the software programs to make sure that it works and meets requirements.

The SQA process can be described as follows:

  • Define Quality Assurance Plans to identify what to do to ensure quality.
  • Support Project Manager to define standards, guidelines and other techniques for the projects
  • Ensure systematic quality control of processes and products such as reviews, inspections, audits as well as configuration management/control, production release, project control, supplier contracting and management, document control, operations and support, maintenance, backup and recovery, and security.
  • Maintain quality records to track issues.
  • Analyze and report on quality issues to management.
  • Maintain and improve quality of products.

Because SQA always checks for any non-compliance and some developers do not like to be monitored, there are often conflicts between them. Some developers consider SQA is like a “police” and do not show much respect to their works.

This is mostly caused by lack of quality training for developers and the fact that many SQA are also NOT well trained and do NOT have enough experiences to demand respect. I have seen many people who work as SQA only have limited software experiences. Many managers do NOT consider SQA as important and often assigned new people, who do not have a lot of experience into this jobs. Some managers even told me: “If they can NOT develop software well, we put them to work as SQA”. This is a very big mistake and that is why many SQA are not so successful in their jobs. That is why so many software have defects.

The most successful SQA usually come from Technical Lead group, who are experienced developers. These people often lead projects, solve technical problems, and provide training to new developers. They know software development well, know development process well, and they are respected by developers. These people are very proactive in guiding, training, and defining the process so by promoting them into SQA is a natural progressing in their career. Many managers argue that since they are very technical, they are needed to work in project but my argument is every project need someone to ensure quality and investment in SQA is essential for the successful of the project.

In my experience, instead of checking for non-compliance and demand corrective actions, the proactive SQA must establish an environment that promotes quality and covers the full life cycle of development from conception through completion. The SQA must communicate the important of process compliance to create quality products and train developers to follow the process accordingly. Rather than merely confirming compliance to plans, QA must ensure that developers understand all necessary steps to create an accurate, complete, and high quality products. Basically a proactive SQA is a teacher, a mentor, a coach, and a guide to help developers to deliver quality products and continually improve the way they develop software.


http://science-technology.vn/?p=2670

Ikigai - A reason for being

http://theviewinside.me/what-is-your-ikigai/


According to the Japanese, everyone has an ikigai. An ikigai is essentially ‘a reason to get up in the morning’. A reason to enjoy life.

Having spent most of the last few years helping dozens and dozens of entrepreneurs find their ikigai, whilst also searching for my own, I can now visualise where it belongs.

graph

Your ikigai lies at the centre of those interconnecting circles. If you are lacking in one area, you are missing out on your life’s potential. Not only that, but you are missing out on your chance to live a long and happy life.

I have had a long time obsession with outliers, and interestingly enough, there are some outlier communities in the world that live far longer than average. If you are interested in learning more about this, watch Dan Buettner’s TED talk on How to Live to 100+. There are some surprising conclusions about the factors that create a long and healthy life. One of the most significant factors is ikigai.

These days, my reason for getting out of bed is to work on projects that reimagine society and education. For someone who spent decades struggling to find a reason to get out of bed, it is now a refreshing change to have this deep sense of purpose. My health and wellbeing have radically improved during recent years, too. The primary reason for this has not been the healthy choices I have made or the diets I have followed, but because I now live with a sense of purpose – and that is the platform for all the other decisions I make.

In The Dandelion Project, we are looking to make Guernsey the best place to live on earth by 2020. Part of that mission is discovering how we can all live a long and healthy life. One of our moonshot goals is for Guernsey to become the first country on earth to have a life expectancy of 100.

We have created this goal to challenge our community to look at healthcare in a radically different way. Living a long life has very little to do with medicine and surgery, which is where most of our health care spending goes. It has everything to do with moving, eating and meaning. All of which can be achieved at no cost to the community.

If we can come together with a collective sense of belief and purpose and take action on this, our population of 65,000 will live longer and be in better health. All without a single doctor’s appointment or pill!

The secret to a long and happy life is not to live in the hope of a great life tomorrow. It is to live with intention today. What I love is that this is possible not only at the individual level, but entire communities can learn from it, as well.

Have you found your ikigai?

– Are you doing something that you love?

– That the world needs?

– That you are good at?

– And that you can be paid for?

How can you live with purpose today, to live a longer and healthier life?

A theory of modern Go

tl;dr;

  • No package level variables
  • No func init

http://peter.bourgon.org/blog/2017/06/09/theory-of-modern-go.html

tl;dr: magic is bad; global state is magic → no package level vars; no func init

The single best property of Go is that it is basically non-magical. With very few exceptions, a straight-line reading of Go code leaves no ambiguity about definitions, dependency relationships, or runtime behavior. This makes Go relatively easy to read, which in turn makes it relatively easy to maintain, which is the single highest virtue of industrial programming.

But there are a few ways that magic can creep in. One unfortunately very common way is through the use of global state. Package-global objects can encode state and/or behavior that is hidden from external callers. Code that calls on those globals can have surprising side effects, which subverts the reader’s ability to understand and mentally model the program.

Functions (including methods) are basically the only mechanism that Go has to build abstraction. Consider the following function definition.

func NewObject(n int) (*Object, error)

By convention, we expect that functions of the form NewXxx are type constructors. That expectation is validated when we see that the function returns a pointer to an Object, and an error. From this we can deduce that the constructor function may or may not succeed, and if it fails, that we will receive an error telling us why. We observe that the function takes a single int parameter, which we assume controls some aspect or capability of the returned Object. Presumably, there is some constraint on n, which, if not met, will result in an error. But because the function takes no other parameter, we expect it should have no other effect, beyond (hopefully) allocating some memory.

By reading the function signature alone, we are able to make all of these deductions, and build a mental model of this function. This process, applied repeatedly and recursively from the first line of func main, is how we read and understand programs.

Now, consider if this were the body of the function.

func NewObject(n int) (*Object, error) {
	row := dbconn.QueryRow("SELECT ... FROM ... WHERE ...")
	var id string
	if err := row.Scan(&id); err != nil {
		logger.Log("during row scan: %v", err)
		id = "default"
	}
	resource, err := pool.Request(n)
	if err != nil {
		return nil, err
	}
	return &Object{
		id:  id,
		res: resource,
	}, nil
}

The function invokes a package global database/sql.Conn, to make a query against some unspecified database; a package global logger, to output a string of arbitrary format to some unknown location; and a package global pool object of some kind, to request a resource of some kind. All of these operations have side effects that are completely invisible from an inspection of the function signature. There is no way for a caller to predict any of these things will happen, except by reading the function and diving to the definition of all of the globals.

Consider this alternative signature.

func NewObject(db *sql.DB, pool *resource.Pool, n int, logger log.Logger) (*Object, error)

By lifting each of the dependencies into the signature as parameters, we allow readers to accurately model the scope and potential behaviors of the function. The caller knows exactly what the function needs to do its work, and can provide them accordingly.

If we’re designing the public API for this package, we can even take it one helpful step further.

// RowQueryer models part of a database/sql.DB.
type RowQueryer interface {
	QueryRow(string, ...interface{}) *sql.Row
}

// Requestor models the requesting side of a resource.Pool.
type Requestor interface {
	Request(n int) (*resource.Value, error)
}

func NewObject(q RowQueryer, r Requestor, logger log.Logger) (*Object, error) {
	// ...
}

By modeling each concrete object as an interface, capturing only the methods we use, we allow callers to swap in alternative implementations. This reduces source-level coupling between packages, and enables us to mock out the concrete dependencies in tests. Testing the original version of the code, with concrete package-level globals, involves tedious and error-prone swapping-out of components.

If all of our constructors and functions take their dependencies explicitly, then we no longer have any use for globals. Instead, we can construct all of our database connections, our loggers, our resource pools, in our func main, so that future readers can very clearly map out a component graph. And we can very explicitly pass those dependencies to the components that use them, so that we eliminate the comprehension-subverting magic of globals. Also, observe that if we have no global variables, we have no more use for func init, whose only purpose is to instantiate or mutate package-global state. We can then look at all uses of func init with appropriate suspicion: what is this code doing? Why is it not in func main, where it belongs?

It’s not only possible, but quite easy, and actually extremely refreshing, to write Go programs that are practically free of global state. In my experience, programming in this way is not noticeably slower or more tedious than using global variables to shrink function definitions. On the contrary: when a function signature reliably and completely describes the behavior-scope of the function body, we can reason about, refactor, and maintain code in the large much more efficiently. Go kit has been written in this style since the very beginning, to its great benefit.

— – -

From this, we can develop a theory of modern Go. Based on the words of Dave “Humbug” Cheney, I propose the following guidelines:

  • No package level variables
  • No func init

There are exceptions, of course. But from these rules, the other practices follow naturally.

Talking with customers

There is a common belief among software developers that they must code as soon as possible since there is not enough time for other activities. That is why many start to write code as soon as they receive the requirements specification without spending time to understand the customers’ needs. No one would ask customers about their expectation or their needs. Most developers ignore the architecture phase; spend little time in design, just to draw some diagrams such as data flow diagram than jump into coding. If they do not understand something, they would guess on what is needed and hurry to get the project done to meet the schedule.

The result is often a software product that does not work as expect and they have to re-work to get what customers’ wants. This situation costs the company time, efforts and a lot of money. Today few colleges teach requirements engineering course, and even if they do, few developers would follow it. The reason among developers is talking with customers takes time and they do not have time. One developer told me: “It is difficult to understand what customers want as they change their mind often”. A project manager explained: “We cannot talk to customers; they would demand more things and waste our time.” When I asked: “What happen if the requirements specification is not clear? How do you know what to do if you do not want to ask? The common answer is: “We just guess what they want. If we are good at guessing, we will be fine but if not then we have to fix it later.”

Of course, most of the time they will produce something that customers do not want and that means more re-work, more costs to the company. I can understand why developers are reluctant to talk to customers; most are not trained and do not know what to ask so they think customers will ask for more and never be satisfied. But I cannot understand why managers do not talk to customers if the project continues to have high re-work rate? Until we establish a good dialogue between developers and customers, software development is just guesswork and costly projects.

There is an urgent need to teach requirements engineering course in the undergraduate program so students can learn how to discuss requirements with customers, determine their needs, set priorities and reduce the issue of re-work. Students should learn incremental releases that add functionality over time. Students should learn to talk with customers by asking questions about functionality and how customers will use their product. Once developers start talking to customers, they will learn many things about how the customers do their work and what they really need. Customers can help explain and clarify functionality written in the specification etc. When both sides engage in discussion about how long it takes to develop a project, they can exchange ideas, develop better solutions and agree on a better schedule for the project.


http://science-technology.vn/?p=1320

Web Developer Roadmap

https://github.com/kamranahmedse/developer-roadmap

The purpose of this roadmap is to give you an idea about the landscape and to guide you if you are confused about what to learn next and not to encourage you to pick what is hip and trendy. You should grow some understanding of why one tool would better suited for some cases than the other and remember hip and trendy never means best suited for the job

UITableView Layout from Bottom

Hôm qua, trong lúc làm UI của App Dental thì mình gặp một trường hợp khá thú vị.
Ở đây, Ly Nguyễn có thiết kế 1 layout table view dạng từ Bottom to Top.
screen shot 2018-07-10 at 09 22 39

Research khá nhiều bài trên StrackOverflow thì đa số quy về 2 cách giải quyết:
1 - Xoay TableView upsidedown và xoay ngược lại các cell bên trong của nó.
Nhược điểm: Scroll view indicator bị xoay theo về bên trái, phải revert datasource.
Xoay lại các cell 1 lần nữa.
Swipe to delete bị sai.
2 - Tính total height của tất cả các cell + header + footer rồi đẩy xuống bằng cách set UIEdgeinsetTop.
Nhược điểm: nặng + khó làm với Autolayout.

Tìm ra giải pháp khác:
UILabel khi set multiple + autolayout thì nó tự tính được content size dựa trên Font size + số kí tự..
Có thể áp dụng giải pháp tương tự
-> Table cần tính intrinsic layout dựa trên content size
`class IntrinsicTableView: UITableView {

override var contentSize:CGSize {
    didSet {
        self.invalidateIntrinsicContentSize()
    }
}

override var intrinsicContentSize: CGSize {
    self.layoutIfNeeded()
    return CGSize(width: UIViewNoIntrinsicMetric, height: contentSize.height)
}

}`
-> Set Layout cho left right bottom.
-> Set Top layout >= 0 để view có thể co dãn từ top về bottom và không cao hơn parent view

view.addSubview(tableView) tableView.snp.makeConstraints { (m) in m.left.bottom.right.equalToSuperview() m.top.greaterThanOrEqualToSuperview() }

Kết quả, loại bỏ được việc tính chiều cao Headers, Footers, Cells, keep Swipe to do something..
screen shot 2018-07-10 at 09 34 58

Mở rộng ra, chưa thử nhưng có thể nhúng tableview vào tableview cell.

"True" full height hero on mobile

window.innerHeight is your best bet.

Below method work on both android/chrome and ios/safari. One caveat is that you will see a flash from 100vh to window.innerHeight (at least on https://dautu.io) because the initial html is static-generated, and window is only avaible on client side.

componentDidMount() {
  this.container.style.minHeight = `${window.innerHeight}px`
}

<div ref={this.setRef} className="min-h-screen">...</div>

Software Design

A programmer wrote to me: “Why do we have to document software design? Is it possible keeping the design in your mind and start to write code instead? What is the difference between architecture and design?

Answer: Basically design is a map of the software product that you are going to build. If you are the only person who build the product then it is possible not to document it. You can start coding from what you have in mind.

However, today most people develop software in team. Your team members cannot read your mind so you need to document your design to communicate the concepts to other people in the project. Typical Design has two major parts: The high level or the architecture and the low level or the detailed design.

Design document describes areas that need to be investigated to identify what may works and what may not. Since software project is done by a team of people, it is important to share the design so the team can evaluate and discuss to identify any errors early in the project. Since software requirements often change, the design provides a common reference point for the team to assess the impact of changes and make design decisions.

The high level or the software architecture indicates how the system is divided into major components; how these components are related to each other; how they interfaces to the user; how they interact to other systems; and how they interact between themselves. The software architecture also identifies data definitions; what data will be stored and where they will be stored. The architect identifies system constraints, quality attributes such as performance, expansion, security, portability and platform technology (e.g., PC-based, cloud-based).

From the architecture, developers shifts to the low-level or detailed design where they breakdown each component into smaller modules where each functions could be specified as well as its constraints on its interface. Each module should also have entry and exit criteria with internal data structures and algorithms defined.

Design information can be documented in textual notes (e.g., “The server responds every 5 seconds with XYZ output,” “Component ABC will handle all errors,” or “The databases will be synced every 5 minutes:”) or it can be documented in graphical form (e.g., modeling languages, UML, event tables, context diagram, flow diagrams, timing diagrams etc.) or it can be documented as pseudo code – a textual description of what the code will do.


http://science-technology.vn/?p=695

Reproduce filter function in Swift

As we know Swift support functional programming language.
The easy to see benefits from that is how easy to use filter, map, flatmap, reduce, sort etc… on Array instead of loop though array
We are not going to explain what functional programming is in this topic, just one thing keep in mind: it accept function as parameter(s) of function.

To explain how it work, let reproduce filter function

let array = [1,2,0,3 ,7]
Apple filter: 
let largeThanOnes = array.filter{$0 > 1}
// print [2,3,7]

Let build our custom one
Extension existed Swift array to add “myFilter” function


extension Array{
  1.  func myFilter(_ condition:(Element)->Bool) -> [Element] {
  2.     var temp:[Element] = []
  3.      for t in self {
  4.         if condition(t) {
                temp.append(t)
            }
        }
  5.      return temp
    }
}

  • This func named “myFilter” and has one parameter: “ (Element)->Bool “.
  • The parameter is a closure "condition" take “Element” of array as it parameter them return true/false logic.
  • The myFilter function return new Array of "Element" that match parameter “condition”
  • Temp array hold filtered Element
  • Loop though array to check each element
  • If element match condition then put it in temp array
  • Return Filtered Array

How to use it

let array = [1,2,0,3 ,7]
array.myFilter({item in 
	return item > 0 
})

However swift can omit closure to become sorter because it can access item by position and inference return type
array.myFilter({$0 > 1})

and sorter
array.myFilter{$0 > 1}

Result:
Reproduce Swift filter.

Concussion:
Apply functional programming help our code easy to write, easy to read(readable) easy to understand, reduce code to write.

Requirement engineering position

A Software Engineering student asked: “I will graduate in coming July. I want to work as a Requirements Engineer or Business Analyst but I do not see much advertising on these positions. What are the opportunities for this job and how do I get this type of position? Please help.”

Answer: Requirements Engineer, Business Analysts, and System Analyst positions often require several years of experience. Most companies prefer to hire people from within their company to fill these positions rather than advertise because the job requires knowledge of the company’s business and their projects. Requirements Engineer (R.E) main function is to gather, analyze, document and validate the needs of their customers for projects. Since R.E represents the company when working with customers they must have good knowledge of the business of the company so they can disseminate company’s products and services information to address the needs of customers. Basically, R.E position is usually a promotion from within instead of advertising for job opening.

Requirements Engineering works require a lot of software development experience to determine customers’ needs and transform them into requirements specifications that the software team can implements. Unclear or wrong requirements could take the project to implement something customers do not want and it is costly for business. An experienced R.E must be able to define the business needs as well as the reason to start a project in alignment with the company’s business. Therefore beside technical skills R.E must also have good soft-skills such as communication, presentation, collaboration, analysis etc. An experienced R.E can help users to describe the capabilities they need to meet their business objectives. Most users often describe the functional requirements in a vague and abstract way, and do not pay attention to the quality attributes, performance goals, business rules, external interfaces but the job of the R.E is to come up with these requirements and write them in the requirements specifications so the software team can build them correctly.

Most Requirements Engineering and Business Analyst positions require a Bachelor’s degree in Computer Science, Software Engineering or Information System Management with strong soft-skills and at least 3 to 5 years of experience. My advice is you should start as a software developer first to build your project’s experience and learn more about the company’s business. After few years, you could move up to technical lead position to understand more about how the project is implemented then transfer to the R.E position.


http://science-technology.vn/?p=4566

Issue in Android Fragment : still click on previous fragment

Khi mình cùng Khanh làm dự án Sol, chúng tôi đã đã implement UI dạng backdrop: các bạn có thể xem tại đây để biết dạng UI này: https://material.io/design/components/backdrop.html

Cách mình dùng để chuyển đổi các screen trong back screen là sử dụng fragment.
Để di chuyển qua 1 fragment khác, ai cũng biết ta có thể dùng 2 cách : add hoặc replace.
Cách replace thì chúng ta sẽ ko gặp vấn đề như title bài til này.
Khi dùng replace, ta move sang 1 fragment khác, khi back lại, fragment previous sẽ được create lại.
Nếu ta muốn fragment đầu vẫn giữ và ko destroy, 1 fragment khác add vào stack sẽ nằm trên fragment này ta sẽ dũng add
Và từ đây ta có 1 issue
Dù đang ở fragment sau khi ta nhấp vào 1 vùng click của fragment trước, sự kiện click vẫn được trigger.

Lý do:
Không giống như activity, khi di chuyển qua 1 screen khác là bạn move hẳn sang 1 view hoàn toàn mới.
Còn fragment được đặt trong 1 view của framelayout, khi replace thì chỉ có 1 view của 1 fragment, còn dùng add thì 1 viewgroup này chồng lên 1 viewgroup của fragment cũ.
Những vùng mà có sự kiện click của fragment trước vẫn detect được khi fragment mới ko có clickable trên những vùng click đó.

Solution:
Cách đơn giản nhất để resolve này là set android:clickable="true" cho root của current fragment

Có thể có 1 số cách khác, nhưng dài dòng hơn:

  • Remove the onClickListener from the main fragment in OnPause, and set it in OnResume. That way, any time the main fragment is not the active fragment, it cannot be clicked.
  • Subclass your top level layout in your VenueFragment and override OnTouchEvent to return true. This will essentially do the same thing as setting an onClickListener, but you may find that it makes your intention to block all touch events clearer.

Vài best practice khi hỗ trợ accessibility trong android

Trong Google IO 2019 đầu năm nay, có 1 chủ đề được thuyết trình đó là Mobile Accessibility: making sure everyone can use what you create.

Thành và @phucledien thấy đây là 1 chủ đề đáng lưu ý mà hiện tại đa số những bạn lập trình viên ko để ý tới. Sau khi research về topic này, thì những lý do vì sao nên support Accessibility sẽ ko đề cập đến trong bài viết này. Xin chỉ note lại những best practice để khi lập trình chúng ta sẽ follow để có thể improve được app cho những người dùng bị khiếm khuyết có thể sử dụng.

*Bật tính năng TalkBack (tính năng để support accessibility) : Có thể xem hướng dẫn tại đây
https://codelabs.developers.google.com/codelabs/basic-android-accessibility/index.html#2
Hướng dẫn sử dụng app khi đã enable TalkBack: https://codelabs.developers.google.com/codelabs/basic-android-accessibility/index.html#3

Content Labeling
Tip for developer:

  • Hint: It is a best practice to use android:hint instead of contentDescription on EditTexts.
  • Do not add placeholder labels to dismiss lint warnings. Temporary lint warnings reminding you to add content descriptions to clickable content (or other placeholder descriptions) can be confusing.
  • While it is common to override setContentDescription, you should never override getContentDescription().

Here are some tips that can enhance the experience for TalkBack users:

  • Keep content brief. This is especially applicable to users w/braille displays, which are often limited to 40-character lines.
  • Don't include words that describe how users should physically interact (e.g. click, tap, press) with your controls in your content description. Let the AccessibilityService itself take care of that. Accessibility includes more than just TalkBack users - for example, Switch Access or Voice Access users will not physically touch the screen at all.
  • Have the most semantically important information come first in your content label. This way, if users don't need or want to hear the rest, they can mute audio feedback.

Grouping Content

The best practices for grouping and ordering elements in an accessible manner can be summarized like this:

  • The view hierarchy order and on-screen positioning determine grouping and ordering of text in spoken feedback.
  • You should group non-focusable items in a focusable container to have them read as a single item.
  • If necessary, set an android:ContentDescription on a container to override automatic grouping and ordering of contained items (we didn't need to do this in the codelab).
  • To logically group related items, it is sometimes necessary to create nested ViewGroups.

Using a Live Region

Carefully consider when using live regions, as announcements for frequently changing views can be disruptive and annoying. Live regions can easily be overused, especially when you're just starting out with accessibility. Live regions are the exception, not the rule.

Custom Views

  • Since the Android framework has baked in accessibility in its default widgets, you should always try to extend these whenever possible. If a custom view is absolutely necessary, you need to make it accessible. If you don't, a service like TalkBack will skip it entirely, badly degrading the experience for users.
  • Complex views that act as containers require special attention, since children need separate focus, clickable actions, etc.

Turning off TalkBack

Hint: scrolling with two fingers in TalkBack is equivalent to scrolling with one finger when not using TalkBack.

Making Touch Targets Large

  • In general, you want the touchable area of focusable items to be a minimum of 48dp X 48dp. Larger than that is even better.
  • Hint: Adding minWidth and minHeight is just one way of expanding the touch area of a view. You can also achieve similar results with adding padding or using the TouchDelegate API.

Ensuring Adequate Color Contrast

  • Low contrast ratios between foreground and background colors can cause views to blur together for some users
  • The Web Content Accessibility Guidelines recommend a minimum contrast ratio of 4.5:1 for all text, with a contrast ratio of 3.0:1 considered acceptable for large or bold text, and you should try to meet or exceed these contrast ratios in your applications.
  • You can use one of the many contrast checkers available online to check your contrast ratios. Or, you can use the Accessibility Scanner.

Accessibility Scanner

  • Google offers an Accessibility Scanner tool that suggests accessibility improvements for Android apps—such as enlarging small touch targets, increasing contrast, and providing content descriptions—so that individuals with accessibility needs can use your app more easily.
  • Note: while tools like Scanner can help you easily resolve low-hanging fruit bugs in your apps, they're no replacement for manual testing.
  • Accessibility needs to be approached holistically - Scanner, for example, won't tell you if your user interface conveys semantic information simply and clearly, or how well it supports multiple modes of interaction (touch vs voice), or if performing your app's most common use cases with TalkBack is efficient.
  • Always remember to test with real users.

Reference:
https://developer.android.com/guide/topics/ui/accessibility
https://codelabs.developers.google.com/codelabs/basic-android-accessibility/index.html#0

The Four Stages of Life

https://markmanson.net/four-stages-of-life


Life is a bitch. Then you die. So while staring at my navel the other day, I decided that that bitch happens in four stages. Here they are.

Stage One: Mimicry

We are born helpless. We can’t walk, can’t talk, can’t feed ourselves, can’t even do our own damn taxes.

As children, the way we’re wired to learn is by watching and mimicking others. First we learn to do physical skills like walk and talk. Then we develop social skills by watching and mimicking our peers around us. Then, finally, in late childhood, we learn to adapt to our culture by observing the rules and norms around us and trying to behave in such a way that is generally considered acceptable by society.

The goal of Stage One is to teach us how to function within society so that we can be autonomous, self-sufficient adults. The idea is that the adults in the community around us help us to reach this point through supporting our ability to make decisions and take action ourselves.

But some adults and community members around us suck.1 They punish us for our independence. They don’t support our decisions. And therefore we don’t develop autonomy. We get stuck in Stage One, endlessly mimicking those around us, endlessly attempting to please all so that we might not be judged.2

In a “normal” healthy individual, Stage One will last until late adolescence and early adulthood.3 For some people, it may last further into adulthood. A select few wake up one day at age 45 realizing they’ve never actually lived for themselves and wonder where the hell the years went.

This is Stage One. The mimicry. The constant search for approval and validation. The absence of independent thought and personal values.

We must be aware of the standards and expectations of those around us. But we must also become strong enough to act in spite of those standards and expectations when we feel it is necessary. We must develop the ability to act by ourselves and for ourselves.

Stage Two: Self-Discovery

In Stage One, we learn to fit in with the people and culture around us. Stage Two is about learning what makes us different from the people and culture around us. Stage Two requires us to begin making decisions for ourselves, to test ourselves, and to understand ourselves and what makes us unique.

Stage Two involves a lot of trial-and-error and experimentation. We experiment with living in new places, hanging out with new people, imbibing new substances, and playing with new people’s orifices.

In my Stage Two, I ran off and visited fifty-something countries. My brother’s Stage Two was diving headfirst into the political system in Washington DC. Everyone’s Stage Two is slightly different because every one of us is slightly different.

Stage Two is a process of self-discovery. We try things. Some of them go well. Some of them don’t. The goal is to stick with the ones that go well and move on.

Man sitting on cliff looking out over clouds

Stage Two lasts until we begin to run up against our own limitations. This doesn’t sit well with many people. But despite what Oprah and Deepak Chopra may tell you, discovering your own limitations is a good and healthy thing.

You’re just going to be bad at some things, no matter how hard you try. And you need to know what they are. I am not genetically inclined to ever excel at anything athletic whatsoever. It sucked for me to learn that, but I did. I’m also about as capable of feeding myself as an infant drooling applesauce all over the floor. That was important to find out as well. We all must learn what we suck at. And the earlier in our life that we learn it, the better.

So we’re just bad at some things. Then there are other things that are great for a while, but begin to have diminishing returns after a few years. Traveling the world is one example. Sexing a ton of people is another. Drinking on a Tuesday night is a third. There are many more. Trust me.

Your limitations are important because you must eventually come to the realization that your time on this planet is limited and you should therefore spend it on things that matter most. That means realizing that just because you can do something, doesn’t mean you should do it. That means realizing that just because you like certain people doesn’t mean you should be with them. That means realizing that there are opportunity costs to everything and that you can’t have it all.

There are some people who never allow themselves to feel limitations — either because they refuse to admit their failures, or because they delude themselves into believing that their limitations don’t exist. These people get stuck in Stage Two.

These are the “serial entrepreneurs” who are 38 and living with mom and still haven’t made any money after 15 years of trying. These are the “aspiring actors” who are still waiting tables and haven’t done an audition in two years. These are the people who can’t settle into a long-term relationship because they always have a gnawing feeling that there’s someone better around the corner. These are the people who brush all of their failings aside as “releasing” negativity into the universe or “purging” their baggage from their lives.

At some point we all must admit the inevitable: life is short, not all of our dreams can come true, so we should carefully pick and choose what we have the best shot at and commit to it.

But people stuck in Stage Two spend most of their time convincing themselves of the opposite. That they are limitless. That they can overcome all. That their life is that of non-stop growth and ascendance in the world, while everyone else can clearly see that they are merely running in place.

In healthy individuals, Stage Two begins in mid- to late-adolescence and lasts into a person’s mid-20s to mid-30s.4 People who stay in Stage Two beyond that are popularly referred to as those with “Peter Pan Syndrome” — the eternal adolescents, always discovering themselves, but finding nothing.

Stage Three: Commitment

Once you’ve pushed your own boundaries and either found your limitations (i.e., athletics, the culinary arts) or found the diminishing returns of certain activities (i.e., partying, video games, masturbation) then you are left with what’s both a) actually important to you, and b) what you’re not terrible at. Now it’s time to make your dent in the world.

Stage Three is the great consolidation of one’s life. Out go the friends who are draining you and holding you back. Out go the activities and hobbies that are a mindless waste of time. Out go the old dreams that are clearly not coming true anytime soon.

Then you double down on what you’re best at and what is best to you. You double down on the most important relationships in your life. You double down on a single mission in life, whether that’s to work on the world’s energy crisis or to be a bitching digital artist or to become an expert in brains or have a bunch of snotty, drooling children. Whatever it is, Stage Three is when you get it done.

Tattooed man with baby

Stage Three is all about maximizing your own potential in this life. It’s all about building your legacy. What will you leave behind when you’re gone? What will people remember you by? Whether that’s a breakthrough study or an amazing new product or an adoring family, Stage Three is about leaving the world a little bit different than the way you found it.

Stage Three ends when a combination of two things happen: 1) you feel as though there’s not much else you are able to accomplish, and 2) you get old and tired and find that you would rather sip martinis and do crossword puzzles all day.

In “normal” individuals, Stage Three generally lasts from around 30-ish-years-old until one reaches retirement age.

People who get lodged in Stage Three often do so because they don’t know how to let go of their ambition and constant desire for more. This inability to let go of the power and influence they crave counteracts the natural calming effects of time and they will often remain driven and hungry well into their 70s and 80s.5

Stage Four: Legacy

People arrive into Stage Four having spent somewhere around half a century investing themselves in what they believed was meaningful and important. They did great things, worked hard, earned everything they have, maybe started a family or a charity or a political or cultural revolution or two, and now they’re done. They’ve reached the age where their energy and circumstances no longer allow them to pursue their purpose any further.

The goal of Stage Four then becomes not to create a legacy as much as simply making sure that legacy lasts beyond one’s death.

This could be something as simple as supporting and advising their (now grown) children and living vicariously through them. It could mean passing on their projects and work to a protégé or apprentice. It could also mean becoming more politically active to maintain their values in a society that they no longer recognize.

Old Woman Praying

Stage Four is important psychologically because it makes the ever-growing reality of one’s own mortality more bearable. As humans, we have a deep need to feel as though our lives mean something. This meaning we constantly search for is literally our only psychological defense against the incomprehensibility of this life and the inevitability of our own death.6 To lose that meaning, or to watch it slip away, or to slowly feel as though the world has left you behind, is to stare oblivion in the face and let it consume you willingly.

What’s the Point?

Developing through each subsequent stage of life grants us greater control over our happiness and well-being.7

In Stage One, a person is wholly dependent on other people’s actions and approval to be happy. This is a horrible strategy because other people are unpredictable and unreliable.

In Stage Two, one becomes reliant on oneself, but they’re still reliant on external success to be happy — making money, accolades, victory, conquests, etc. These are more controllable than other people, but they are still mostly unpredictable in the long-run.

Stage Three relies on a handful of relationships and endeavors that proved themselves resilient and worthwhile through Stage Two. These are more reliable. And finally, Stage Four requires we only hold on to what we’ve already accomplished as long as possible.

At each subsequent stage, happiness becomes based more on internal, controllable values and less on the externalities of the ever-changing outside world.

Inter-Stage Conflict

Later stages don’t replace previous stages. They transcend them. Stage Two people still care about social approval. They just care about something more than social approval. Stage 3 people still care about testing their limits. They just care more about the commitments they’ve made.

Each stage represents a reshuffling of one’s life priorities. It’s for this reason that when one transitions from one stage to another, one will often experience a fallout in one’s friendships and relationships. If you were Stage Two and all of your friends were Stage Two, and suddenly you settle down, commit and get to work on Stage Three, yet your friends are still Stage Two, there will be a fundamental disconnect between your values and theirs that will be difficult to overcome.

Generally speaking, people project their own stage onto everyone else around them. People at Stage One will judge others by their ability to achieve social approval. People at Stage Two will judge others by their ability to push their own boundaries and try new things. People at Stage Three will judge others based on their commitments and what they’re able to achieve. People at Stage Four judge others based on what they stand for and what they’ve chosen to live for.

The Value of Trauma

Self-development is often portrayed as a rosy, flowery progression from dumbass to enlightenment that involves a lot of joy, prancing in fields of daisies, and high-fiving two thousand people at a seminar you paid way too much to be at.

Street graffiti showing abstract human portrait

But the truth is that transitions between the life stages are usually triggered by trauma or an extreme negative event in one’s life. A near-death experience. A divorce. A failed friendship or a death of a loved one.

Trauma causes us to step back and re-evaluate our deepest motivations and decisions. It allows us to reflect on whether our strategies to pursue happiness are actually working well or not.

What Gets Us Stuck

The same thing gets us stuck at every stage: a sense of personal inadequacy.

People get stuck at Stage One because they always feel as though they are somehow flawed and different from others, so they put all of their effort into conforming into what those around them would like to see. No matter how much they do, they feel as though it is never enough.

Stage Two people get stuck because they feel as though they should always be doing more, doing something better, doing something new and exciting, improving at something. But no matter how much they do, they feel as though it is never enough.

Stage Three people get stuck because they feel as though they have not generated enough meaningful influence in the world, that they make a greater impact in the specific areas that they have committed themselves to. But no matter how much they do, they feel as though it is never enough.8

One could even argue that Stage Four people feel stuck because they feel insecure that their legacy will not last or make any significant impact on the future generations. They cling to it and hold onto it and promote it with every last gasping breath. But they never feel as though it is enough.

The solution at each stage is then backwards. To move beyond Stage One, you must accept that you will never be enough for everybody all the time, and therefore you must make decisions for yourself.

To move beyond Stage Two, you must accept that you will never be capable of accomplishing everything you can dream and desire, and therefore you must zero in on what matters most and commit to it.

To move beyond Stage Three, you must realize that time and energy are limited, and therefore you must refocus your attention to helping others take over the meaningful projects you began.

To move beyond Stage Four, you must realize that change is inevitable, and that the influence of one person, no matter how great, no matter how powerful, no matter how meaningful, will eventually dissipate too.

And life will go on.

zsh: set iTerm window title

Add those lines to your .zshrc

set-window-title() {
    window_title="\033]0;${PWD##*/}\007"
    echo -ne "$window_title"
}

PR_TITLEBAR=''
set-window-title
add-zsh-hook precmd set-window-title

screen shot 2017-02-08 at 1 00 04 am

How to quick create Object from JSON

Today, I going to introduce a quick method to create our custom object from JSON.

All we need to do is:

  1. Install VSCode if you didn't have one.
  2. Install VSCode Paste JSON as Code Extension

To install VS code on MAC OS your can run brew cask install visual-studio-code or quick search how to install on Google.

Open VS code, Click on Extension and search for Parste JSON and Install it.
screen shot 2018-07-23 at 10 04 55

Now you need quit and reopen your VSCode.
Create new JSONFile with .json extension
Press Command + Shift + P to open menu
screen shot 2018-07-23 at 10 10 08
Choose Open Quick type for JSON
Press Command + Shift + P again to set quick type target language
I'm using Swift so I choose Swift
Now you can see JSON convert to your target language
screen shot 2018-07-23 at 10 16 55
Now simple copy your object to use.

Custom Max Height, Max Width for view on android

Trong 1 view của android không hỗ trợ cho việc set max height , nhưng đôi khi có những trường hợp bạn cần 1 view wrap content và muốn có chiều ngang hoặc chiều dọc tối đa thì android lại ko support sẵn. Việc chúng ta làm là sẽ custom lại view đó, ta sẽ override lại trong hàm onMeasure

@Override
protected void onMeasure(int widthSpec, int heightSpec) {
    heightSpec = MeasureSpec.makeMeasureSpec(Utils.dpsToPixels(240), MeasureSpec.AT_MOST);
    super.onMeasure(widthSpec, heightSpec);
}

Systemic software development

Systemic software development

A software developer wrote to me: “We had several project failures. Customers were angry but the project manager told us that they were customer’s faults because they kept changing requirements. We are starting a new project but I am afraid that we will make the same mistake again. What can we do to avoid this problem? Please advice.”

Answer: If the customers keep changing requirements then you need to have a requirements engineer or business analyst to spend time with customers to obtain better requirements. This is an important role in software development but many companies do not pay attention. If the requirements are wrong than everything will be wrong no matter how good you can design or code. If your company does not have someone to do this then they should hire people who could do that job. When a project fails, your manager should not blame the customers but should identify the cause and fix it so it will not happen again. When customers are not happy then it is bad business. No company can survive if their customers are not happy. When a project is late, it takes more time, more money, and more efforts than previously planned. It means the company has to pay for these extra works and it means losing more money.

Changing requirements is a common problem in software industry. It is usually due to the lack of knowledge on software requirements. Many project managers think that they understand what the customers need and proceed to development without any customer validation. Many developers presume that they know all the features customers need then start design and code without any customer review. Progress is measured by each line of code built throughout the process until requirements begin to change. Fixing software after building is costly and time consuming. It often causes huge effort waste with hundreds of hours unproductive and hundred lines of code changes. This is why you need someone who understands requirements to work closely with customers to get the right requirements so you do not make the same mistake again.

There are different views of requirements. A manager’s view of requirements is often a high-level concept of a product or a business problem that must be solved. A user’s view of requirements is mostly the functions, the interface, and the navigation of screens. If the requirements are mostly functional, the project team may not understand various information hidden under the view of functionality. As a result, customer’s expectations may not be achieved.

To avoid this issue, project team must understand several views of requirements. The highest level view is the business requirements, representing the objectives of the customer. This is really the vision and the scope of your project. The second level view is the user’s requirements, which describe all the tasks that users must do when using the software. These are best captured in the form of use cases, which are scenarios of typical interactions between the user and the system. This is the architecture of the system with hardware, software interface and the navigation of screens. However, use cases alone do not provide enough detail for developers to know what to build. Therefore, you need the third level view or the functional view which derive from the use cases. The functional requirements clearly define specific things the software must do. This is the design of the system with each function clearly identified. However, there is another view called the non-functional view or the quality attributes which does not come from customer but from developers that deals with the quality of the software such as performance, efficiency, usability, or scalability etc.

By understand different views, developers can organize their work systematically to meet customers’ expectation and develop better software product.


http://science-technology.vn/?p=1197

RxJava upgraded to version 2.x.x

https://github.com/ReactiveX/RxJava/wiki/Reactive-Streams

RxJava 2.x will target Reactive Streams APIs directly for Java 8+. The plan is to also support Java 9 j.u.c.Flow types by leveraging new Java multi-versioned jars to support this when using RxJava 2.x in Java 9 while still working on Java 8.

RxJava 2 will truly be "Reactive Extensions" now that there is an interface to extend. RxJava 1 didn't have a base interface or contract to extend so had to define it from scratch. RxJava 2 intends on being a high performing, battle-tested, lightweight (single dependency on Reactive Streams), non-opinionated implementation of Reactive Streams and j.u.c.Flow that provides a library of higher-order functions with parameterized concurrency.

Improving software quality

There are several ways to evaluate software quality such as how well it meets requirements, how useful to users, and the number of defects found during testing. However, to many software developers, quality is usually the last thing they check before release to customer. Most quality checks are done during testing phase and it is usually too late. The early you can identify defect, the easier and less costly to fix a defect. According to several studies, every time a defect passes into the next phase, it increases the complexity by a factor of 5 and the fixing cost by a factor of 10. For example, a defect costs $1 to fix in requirements phase will cost $10 to fix in design phase, $100 to fix in coding phase and $1000 to fix during testing phase and $10,000 to fix after release to customer.

Since a wrong requirement can increase complexity in design and code many times, by monitor quality throughout the development process, project managers can decide whether to continue the development or redesign and correct defects instead. Sometime it is better to restart the project rather than continue to fix defect as the software is too complex and difficult to change. During software development phases, project manager must have the ability to track defects in each phase in order to judge the quality of the software at any given time. At the end of each phase, project manager must evaluate both the quality and the completeness to determine whether the project should move to the next phase or not. The best way is to use checklists at the end of each lifecycle phase.

When a defect has been found, project manager must record it in a defect log. It will be assigned a number that allows it to be referenced from creation through resolution. It is important that the defect be given some type of priority that reflects its severity. This priority will determine when it needs to be fixed and whether the defect is serious enough to impact the schedule. Each defect should be assigned to a developer to fix and after it is fixed, quality assurance must make sure that it is fully tested and record the status in the defect log (Open, close). Another important quality factor is the rate at which defects are found. Typically a high find rate is expected during early phases of development, the rate should decrease over time as many of them have been fixed.

Project manager must also evaluate the causes of defects to determine which of its software functions or modules have the most defects. By knowing these error-prone area, manager can take action such as increase more testing in certain areas of the code; redesign a function or module; or assign more experienced developers to work on defect-prone areas.

Companies that track defects and organize them based on severity, priority and other criteria can improve their quality significantly. By constantly evaluate quality at any given time in the development lifecycle, they can improve their quality and reduce defects with greater confidence, knowing that every effort has been made to find and fix defects.


http://science-technology.vn/?p=853

Problem when cannot load facebook profile image on android

When Khanh implement Welcome Back UI on Sol, he needs to load facebook profile image onto ImageView.

He has a problem when we use Glide to load this URL, Glide cannot load it, and if you click this link by browser, it's will download this image and don't show anything. It'so weird, because it just a link to show an image.

So after reviewing the code, we easy to fix it with type one word.
http change to https

eg:
http://graph.facebook.com/2536187389726079/picture?type=large
to
https://graph.facebook.com/2536187389726079/picture?type=large

It easy, right?

Another way to load the facebook profile image onto view:

We will use ProfilePictureView ( widget of Facebook SDK)

<com.facebook.login.widget.ProfilePictureView
    android:id="@+id/image"
    android:layout_width="wrap_content"
    android:layout_height="wrap_content"
    android:layout_centerInParent="true"
    facebook:preset_size="small"/>

After that, you can set facebook id like this in code

profilePictureView.setProfileId(facebookUserId);

RxView.globalLayouts RxView.globalLayouts replace addOnGlobalLayoutListener

Khi ta cần detect layout change trước đây ta thường dùng

myView.getViewTreeObserver().addOnGlobalLayoutListener(new ViewTreeObserver.OnGlobalLayoutListener() {
    @Override
    public void onGlobalLayout() {
    }
});

Chúng ta có thể dùng RxView để làm việc này 1 cách dễ dàng hơn:

 RxView.globalLayouts(info_overlay)
        .map { info_overlay.visibility }
        .distinct()
        .subscribe { newVisibility ->
        }

hoặc

 RxView.layoutChanges(view)
            .distinct()
            .subscribe { newVisibility ->
            }

A brief history of software development

History of modern computer technology is very short, it is only about 70 years. History of software is shorter, it is about 50 years. Most software development methods do not fully take shape until 1970s. Basically, there are two ways to develop software:

The “Classical way” or the “Product-driven way” considers develop software is a building activity with each brick (Code) putting on top of each other until they become the software product. It considers that anyone with programming skills can build software and that activities leading to a software product are “free form” as each programmer know what he is doing. This view came from the early days of computer, a time in which software was still a mystery that depended on programmers to code software. It relies on the individual techniques and knowledge that is in his head and not documented.

The “Modern way” or the “Process-driven way” appeared in the late 1970s is based on the manufacturing area which focus on the way software is built to determines the product’s quality. This way considers software as a set of small tasks that follow a process where each can be controlled and measured. It discards the concept that software development is a “free-form”. It insists that it is a discipline that is best done under strict rules in which relationships between tasks are well defined explicitly. These relationships, also known as “process”, identify the tasks needed to produce a software product and guide it through a roadmap called “Software development life cycle”.

Most software projects today either follow the “Classical” or the “Modern” way depends on the education and training of developers. Between 1970s to 1990s, the software industry focused mostly on the classical way since most software at that time were relatively small and more simple. However the quality of those software was not very good with many defects. The shift from “Classical way” to “Modern way” began in the late 1980s when the US government’s wanted to improve the quality of software in military embedded systems by demanded that all software works for government must follow strict quality standards. This was manifested with the Ada programming language and its frameworks for common methods and tools such as DOD-STD-2167.

The establishment of the Software Engineering Institute (SEI) at CarnegieMellonUniversity in late 1980s is the attempt to improve quality of software throughout the U.S. The development and application of the Capability Maturity Model for Software (CMM) and several process models appeared later have changed the way people develop software in the U.S and then to other countries.

During the transition time, there is major disagreement between people who are trained in the “Classical way” and the “Modern way”. One group consider following a “process” destroys the individual’s creativity. The other consider not following a process is chaotic and out of control. There are many arguments and debates among developers until evidences from industry clearly demonstrated that standardized process can improve projects’ ability to manage cost, schedule, and defects. Even when companies begin to accept the “Modern way”, universities are still teaching the “Classical way” so students are confused. They are trained to do whatever they can (Free-form) to build software during their four years in college but when they work in the industry, they are forced to follow a “process” in which most do not understand. Many feel uncomfortable by the “ unnecessary bureaucracy” in strongly process-driven efforts. This led to a rebellion in the early 2000s against any “heavyweight” processes such as the CMMI or ISO 9000. A group of developers create a light weight alternative process now known as “The agile processes”.

The fact is for large and complex project, you do need the discipline process to ensure the quality and control aspects. There are enough evidences to show that following a software development process can bring higher quality and better software product on time, within schedule and cost. However, for smaller project, it is acceptable to have a less restriction ways such as Extreme Programming, Scrum, Adaptive Software Development. It is important to understand the benefits of both processes (Modern ways and Agile way) but it is also important to point out that developers should not return to the old classical way of free-form, do whatever you like to build software.


http://science-technology.vn/?p=1971

StopService does not call onDestroy immediately

http://stackoverflow.com/questions/20945847/stopservice-does-not-call-ondestroy-immediately

In my case, I followed the tutorial at Android Developers, which uses a ServiceConnection. In the example code, they call unbindService() but never stopService(). So I added a call to stopService() to stop it, but still onDestroy() never got called.

From the documentation of Context.stopService():

Note that if a stopped service still has ServiceConnection objects bound to it with the BIND_AUTO_CREATE set, it will not be destroyed until all of these bindings are removed.
I interpreted this as it's okay to call stopService() or stopSelf() first, and then unbindService() afterwards (I'm using BIND_AUTO_CREATE) - and that the service would be stopped/destroyed upon calling unbindService().

But it turns out that this isn't the case. When I moved things around so that I'm calling unbindService() first and stopService() after that, my onDestroy() gets called immediately.

Why I like to make everything visible

When working as a team, I always wanted to know what exactly Everything is going on. Or in Scrum, it is defined as Transparency. The perfect world where there is no secret, no hidden agendas, nothing behind the curtain, no room for backstabbing to happen.

When implementing Scrum, a lot of people implement the framework itself but not really understand why it is designed that way. In Scrum, anyone can go to any meeting, not anyone is required to do so.

  • A junior team member can participate in a Scrum Planning to understand how it is done or how the Senior member think or solve a problem
  • Any stakeholder can observe a Daily Stand-up or attend a Review for a better understanding of what is going on in a team
    ...

Transparency is NOT for the manager to micro-manage the individuals but for the team itself to address individual performance issues. When everything is transparent, the team will actually know what people are doing, who is helping, who is hurting, who makes the team great and who makes it painful. That will make the team have its own adjustments and therefore, evolve to a better stage.

Keeping secret from people simply slows everyone down. Plus, it breeds suspicion and distrust. If you can't trust the people you are hiring to be on board with what you are doing, you are either hiring the wrong people OR you have set up a system that has failure in it.

However, transparency is not one people work. Everyone needs to put their effort into the system to make it work. The end goal is simple: Make the work speaks for itself. Make sure everything is in the correct state, discuss the problems in the public chat channels so that everyone can help if they experienced the same issue. Put every material or discussion within the item itself so that everyone can read the history of the discussion and why we came up with the solution...

Once the communication is transparent, there will be no need for the question: What is going on?

Software Engineering Career

Software engineering has been ranked as the hottest job in the world. Basically; software engineer is responsible for creating quality software product that meets customer’s requirements. Software engineering students are trained to architect a software solution based on a set of technology components. They learn to design prototypes to make sure that the solution meets customer’s needs, and write code to create products based on those prototypes. Students learn to follow software process, software lifecycle, and software methods and using tools so by the time they graduate, they have a set of skills that can be applied to many areas. In addition, they also maintain awareness of the latest industry trends and technologies, and provide technical advice to other people.

The future of this field is bright as there are many job opportunities today and in the future. The most interesting thing about software engineering is that graduates can work in so many different fields. Software engineering is part of every industry.

If you are a software engineer working for a software company like Microsoft, Google, Facebook etc. you will be working with other software engineers and be specialized in testing, programming, developing, quality assurance, architecture, and project management etc. If you are a software engineer working in a manufacturing or business company, you could be working on customer Relation Management system (CRM); Enterprise Resource Planning system (ERP); or Supply Chain management system (SCM) and developing software or customize Commercial off the Shelf (COTS) software such as “SAP” or “PeopleSoft” for the company. As more companies are trying to automate their information system, they need more software engineers.

Today Information technology (IT) field that consists of Computer Science, Software Engineering, Information System Management and Computer Engineering are one of the occupations that grow the fastest in the world. In fact, there is a shortage of these people in every country because the demand has exceeded the supply. This growth will continue because there are more businesses need new technologies to streamline the efficiency of their computer systems. All this growth and demand leads to significant increasing salaries. Today starting salaries for software engineer’s graduates in the U.S is ranging from $89,000 to $105,000; with each year of experience add another $5,000 to $7,000. A software engineer with five years of experience can be expected to make $120,000 to $135,000 a year.

Today, mobile platforms and tablets became “Hot” areas. There is high demand for graduates who have skills in developing applications for mobile devices with emphasis on Apple’s iPod, iPhone and iPad or Google’s Androids. The change in technology requires a change in curriculum to focus more on mobile approach. Many programming classes are expanding to cover Java, C++, C#, Python, and Ruby on Rails.

With high global demand, now is a great time to study software engineering or other information technology fields. As you plan for your future career, remember to add foreign language such as English as many jobs in the future require language skills. Today, almost every job in IT industry require a Bachelor degree, some even prefer advanced degrees. Although in some countries, 2 years vocational or certificates are still good to get jobs but the market has changed rapidly. Today most software are becoming larger and more complex, the short training time will not give workers the skills that industry requires, especially if you want to work for global company, outsourcing provider company.

Although, job description varies among companies and specialty areas but most companies want to hire graduates that have experience in software development (Capstone project is often counted as 6 to 8 months experience); Graduates that have knowledge of software development process, lifecycle, design procedures with additional soft-skills such as communication skills, presentation skills, decision making, leadership skills and the most important is teamwork skills (Capstone project is often counted as having teamwork skills).

During job interviews, most companies would ask candidates about skills such as the design and architecture a software systems according to a requirements specification; the ability to work with distributed team members and be able to integrates suggestions and changes (This is why foreign language skill is critical) ; How to conduct unit test components to ensure module-level functionality and data structure consistency; Skills in design and implementation/code reviews of other team members; Skills in writing code in a timely fashion and with high quality, consistent with industry standards. The ability to communicate with customers and users (This is why foreign language is important); and knowledge about the latest industry trends and technologies. (This is why students must read technology news and industry trends often);


http://science-technology.vn/?p=1483

CSS scroll-snap on most browsers

Tested on latest Chrome/Safari/Firefox.

.fullscreen-container {
  --header-height: 81px;
  --section-height: calc(100vh - var(--header-height));

  /* https://caniuse.com/#feat=css-snappoints */
  /* for firefox/edge (old version of the spec) */
  scroll-snap-type: mandatory;
  scroll-snap-points-y: repeat(var(--section-height));

  /* for chrome/safari (new version of spec) */
  scroll-snap-type: y mandatory;

  /* padding top due to fixed header */
  scroll-padding-top: var(--header-height);

  width: 100vw;
  height: 100vh;
  overflow-x: hidden;
  overflow-y: auto;
  -webkit-overflow-scrolling: touch;
}

.fullscreen-child {
  scroll-snap-align: start;
  height: calc(var(--section-height));
}

Important note for Safari

.fullscreen-child must NOT have overflow-x: hidden in order for scroll snaping to work properly on Safari.

Problem with Software

A student asked me: “Why there are so many problems in software industry? What can students learn to avoid these problems?”

Answer: In school, professors always give students clear, well-defined requirements for their assigned works. Students have enough time to complete the work. However, in the industry, most customers rarely give developers good requirements. Most requirements are unclear, incomplete, highly general, not enough details and sometime not testable. Customers often give project team an unrealistic schedule to complete the work. Since customers do not know how long it will take to complete the project so they just guest an arbitrary date. Many project managers do not know how to negotiate with customers for better and more accurate schedule. Many managers also do not know how to estimate the time needed for the project, they just take customer’s schedule and ask developers to follow. If a lot of works are being pushed into a very short time, problems are inevitable. In order to meet the unrealistic schedule, developers skip some phases, hurry to get the code done, and often do not test enough so there are many defects left in the software product. No one know whether the software is good or not until customers complain or software crash. Throughout the software development, customers often change their minds, they think of new things then request new features to be added after the project already started. Project managers do not want to make customers unhappy so they just ask developers to do more without any adjustment in schedule or assignment. That put more pressure on developers, many have to work longer hours, often not getting paid, just to get their works done. In that case, defects are inevitable.

In school, students often work in isolation since teamwork is considered cheating. Good students receive good grade and often being praised by professors so they feel like “heroes”. In the industry, developers work in team and often have to share information to get their works done. However, some developers still want to be “heroes” so they do not share anything, they believe they can succeed by themselves. The lack of teamwork, lack of collaboration, and lack of information, force developers to “assume” certain things. When it turn out that their assumptions are not correct, problems happen. If developers do not know what is needed and what is expected from them, or have erroneous assumptions, problems can be expected.

To solve these problems, students must learn more about requirements engineering to obtain better requirements. They must follow a process to solicit, analyze and verify requirements. If they can get a clear, complete, detailed, and testable requirements then the project is at least have more than 50% chance of success. If not students must learn how to negotiate with customers on schedule and efforts, this is a very good soft skill that students need to learn. Students must learn more about project management, especially how to plan, how to breakdown a large requirements into smaller tasks and estimate the time needed to complete those. Students must learn how to work in team. They should communicate often with each others. Students should learn more about review, inspections to reduce defects when appropriate.

Having a realistic schedules is very important as it allow adequate time for design, testing, defects fixing, re-testing, changes, and documentation. Students must learn how to plan testing by start testing early on, re-test after fixes or changes, plan for adequate time for testing and defect fixing. Once the project started, students must learn to avoid changes, if possible. By prepare to defend against excessive changes and additions after the project started will avoid many problems. If changes are necessary, they should be adequately reflected in schedule changes. If possible, work closely with customers to manage expectations.


http://science-technology.vn/?p=2094

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.