TRUNGTQ

Think Big, Act Small, Fail Fast and Learn Rapidly

NAVIGATION - SEARCH

Nghề lập trình: trước 40 tuổi bạn nên có phương án B

Một bài viết khá hay, ai cũng phải chuẩn bị phương án dự phòng hợp lý.

Lời bàn của Vinacode:

Nhiều lúc mình cũng ngồi suy nghĩ rằng không biết sau 40 tuổi thì mình có ngồi code được nữa không. Ở Mỹ thì việc viết code trọn đời là chuyện bình thường, vì mức thù lao của họ rất lớn có thể đảm bảo một cuộc sống khá sung túc. Nhưng ở Việt Nam thì khác, và tình trạng lập trình viên nước ta cũng giống y chang các đồng nghiệp Ấn Độ như trong bài viết “Những lầm tưởng về lập trình viên Ấn Độ”.

Ở Việt Nam thì mỗi lứa tuổi đều có rất nhiều người xuất thân từ lập trình mà thành đạt, ví như đại diện 6x có thể kể đến Nguyễn Thành Nam – FPT (1961), thế hệ 7x thì có Nguyễn Tử Quảng – BKAV (1975), thế hệ 8x thì Vương Vũ Thắng – VCCorp (1980), Nguyễn Hòa Bình – PeaceSoft (1981). Nhưng số phận của hàng ngàn con người cùng lứa với họ thì ra sao nhỉ, họ đã tản mác về đâu? có bao nhiêu % bám trụ được với nghề? có bao nhiêu % sau 40 tuổi vẫn đang trực tiếp code?

Nếu nước mình cũng có cơ quan thống kê số liệu như ở Mỹ thì hay quá nhỉ?!

P.S. Bạn cũng nên đọc thêm bài viết “Bạn có thể lập trình đến năm bao nhiêu tuổi?” bên TechMaster của tác giả Trịnh Minh Cường

Xin chào mừng bạn trẻ đến thị trấn của những người già.

Trong khi tìm hiểu để viết bài viết gần đây, “Tuổi bị phân biệt đối xử và nghề lập trình viên”, tôi đã khám phá ra một đoạn trích dẫn của tờ báo uy tín New York Times vào năm 1998 tiết lộ một thống kê làm sửng sốt từ cục điều tra NSF của Mỹ về tuổi thọ của nghề lập trình viên.

“Sáu năm sau khi tốt nghiệp đại học, 57% sinh viên tốt nghiệp ngành khoa học máy tính làm việc như là một lập trình viên; sau 15 năm ra trường thì con số này giảm xuống còn 34%, và sau 20 năm ra trường — khi mà hầu hết mọi người đều chớm bước sang tuổi 40 — thì tỉ lệ này rớt xuống còn 19%. Trái ngược hẳn, con số này tương ứng cho kỹ sư xây dựng là 61%, 52% và 52%.”

Sau 20 năm ra trường thì chỉ có 19% kỹ sư phần mềm bám trụ được với nghề lập trình (tại Hoa Kỳ).


Tôi nhận thấy bài báo này có nhiều điểm chưa chính xác khi họ chỉ thống kê những người tốt nghiệp ngành khoa học máy tính để đưa ra kết quả này. Rõ ràng là chính phủ vẫn khá chậm để nắm được rõ đặc thù của nghề phát triển phần mềm. Trong nghiên cứu này họ đã lờ đi một số lượng rất lớn các lập trình viên đang làm việc mà lại có bằng cấp trong một ngành khác hoặc thậm chí chưa tốt nghiệp đại học bao giờ.

Dường như giá trị của một lập trình viên sụt giảm rất nhanh chỉ chậm hơn một chút so với cái máy tính mà anh ta hoặc cô ta ngồi làm việc phía sau chẳng là bao, nếu theo như bình luận của vào năm 1996 của Craig Barrett, người là đồng sáng lập và là chủ tịch của hãng công nghệ khổng lồ Intel.

“Một nửa cuộc đời của một kỹ sư phần mềm hoặc phần cứng chẳng là bao, nó chỉ có mấy năm chứ mấy.”

Chắc chắn là gã này nói đúng, nhưng điều quan trọng hơn đó là ông ta (tại thời điểm đó) nguyên là một kỹ sư già 57 tuổi và công khai nhấn mạnh về sự phân biệt đối xử do tuổi tác của những kỹ sư khác. Thật là kinh hãi khi nghĩ đến một người có ảnh hưởng trong ngành như ông ta cho rằng nghề lập trình phần mềm cũng khắc nghiệt như nghề cầu thủ bóng đá vậy.

Quan điểm của tôi về vấn đề này

Đã có những lời cáo buộc nhắm vào vấn đề phân biệt đối xử vì tuổi tác trong lĩnh vực công nghệ, nhưng tôi ngờ rằng nó là một hệ quả không thể tránh khỏi của những thay đổi nhanh chóng xảy ra trong lĩnh vực này.

Chúng ta hãy cùng cân nhắc một vài vấn đề sau:

  • Giá trị thị trường của một nhân viên thì cơ bản được xác định bởi kinh nghiệm của anh ta trong lĩnh vực công nghệ liên quan đến người sử dụng lao động.
  • Kỹ sư phần mềm chắc chắn sẽ phải chịu đựng một sự dịch chuyển lớn trong công nghệ ít nhất là 10 năm một lần.
  • Trong khi công nghệ dịch chuyển không hoàn toàn phủ định các kỹ năng của một người kỳ cựu, nhưng nó chắc chắn cũng tạo ra sân chơi mới cho những người mới tốt nghiệp.

Bây giờ hãy đặt bản thân mình vào vai trò của một người quản lý đang tìm kiếm thuê nhân viên, và bạn đang sử dụng một công nghệ mới giống như Ruby on Rails thì không có ai khác ngoàiDavid Heinemeier (người là cha đẻ của framework này) có nhiều hơn 5 năm kinh nghiệm trên nó. Chắc chắn là việc có trên 10 năm kinh nghiệm C++ là một lợi thế lớn dành cho một người kỳ cựu so với một người mới chỉ có 3 năm kinh nghiệm Rails. Nếu tất cả mọi thứ ngang nhau thì theo lẽ tự nhiên bạn sẽ thuê gã có tổng số năm kinh nghiệm nhiều hơn.

Tuy nhiên, tất cả điều này cũng KHÔNG ngang nhau. Với 10 năm kinh nghiệm C++ khiến cho ứng viên có nhiều giá trị và được đánh giá cao trong công việc yêu cầu C++. Vấn đề đó là liệu giá trị tăng thêm của cái kinh nghiệm đặc biệt đó có lớn hơn cái giá để thuê anh ta hay không, để ít nhất là dành để trả lương cho họ.

Đây là nguồn gốc của vấn đề. Nhiều kinh nghiệm mà ứng viên có thì lại chả liên quan gì đến công việc cả, và cứ cho là người quản lý tỏ ra hào phóng trả thêm một khoản tiền để được cái kinh nghiệm đó.

Thậm chí nếu giá cả của người kỳ cựu khá cạnh tranh so với một ứng viên trẻ, thì người quản lý cũng quan tâm đến đến một vấn đề không nói ra là nên tuyển về một ai đó mà khi sa thải thì không phải mất một khoản chi phí lớn. Liệu họ sẽ có vấn đề tinh thần (nhuệ khí) ngay ngày đầu tiên làm việc? Họ sẽ thay đổi ý định sau một tháng và sau đó họ thực sự cần một khoản tiền bồi thường để ra đi? Đó là một tình huống rất khó chịu.

Có một sự thật không may đó là không giống như những hình thức phân biệt đối xử khác cái mà thường tùy tiện và thất thường, tuổi bị phân biệt đối xử có thể là kết quả của mục tiêu và tình trạng kinh doanh của doanh nghiệp. Tôi không cố gắng biện hộ đó là một hành động chấp nhận được, nhưng bạn hãy thử đặt mình vào hoàn cảnh đã đẩy người quản lý cố gắng đưa ra những quyết định dựa theo tình hình kinh doanh mà không cần để ý cân bằng giữa đạo đức và trách nhiệm pháp lý của công ty.

Vậy phương án B của bạn là gì?

Giả sử rằng tình trạng tài chính của bạn cũng chả dư giả gì cho lắm, và đến 40 tuổi thì sức khỏe của bạn cũng không còn phong độ như xưa. Thì sau đây là một vài phương án mà có thể tạm chấp nhận được.

Làm việc cho một người nào đó mà sẽ chẳng bao giờ phân biệt đối xử với bạn.

Không. Người đó không phải là mẹ của bạn. Đó chính là bạn! Nếu bạn không phải tuýp người doanh nhân, hãy xem xét đến việc trở thành một nhà tư vấn. Vì một vài nguyên nhân mà tôi không liệt kê hết được các lý do ở đây, nhưng với một mái tóc hoa râm và một số kinh nghiệm trong các công nghệ khác nhau thì bạn có thể tạo ra lợi ích đối với các công ty khi họ thuê bộ não của bạn thay vì việc họ bỏ tiền ra mua hẳn. Cũng có một xu hướng cho các chuyên gia tư vấn là tiến lên các nấc thang cao hơn trong cấp bậc quản lý nơi mà các con “cáo già” khác đang sống.

Tham gia vào công việc quản lý.

Tôi muốn tranh luận rằng nghề lập trình viên thì có một chút thuận lợi để cho ai đó có thể tiến vào công việc quản lý, nhưng rõ ràng là các nhà quản lý nghĩ rằng tất cả mọi người bao gồm cả các chuyên gia công nghệ đều có một khao khát rất lớn để “dần dần” tiến vào hàng ngũ của họ. Tôi nghĩ rằng thật sai lầm khi cho rằng không ai sẽ tiếp tục thiết kế và xây dựng phần mềm trong 20 năm trừ khi họ không có hoài bão và tiềm năng phát triển. Nhưng chúng ta nên quan tâm đến một số vấn đề sau trước khi nhảy vào lĩnh vực quản lý:

  • Các vị trí quản lý ở tầm trung thì thường kiếm được thêm rất ít thu nhập, nếu không muốn nói là ngang bằng với các kỹ sư bậc cao.
  • Càng ngày càng khó để cập nhật các công nghệ mới, bởi vì bạn không làm việc trực tiếp với chúng.
  • Các cuộc họp, chính trị và phải giải quyết những vấn đề linh tinh sẽ trở thành một hoạt động thường xuyên trong cuộc sống của bạn.
  • Bạn có thể cố gắng tránh nó, nhưng phong cách quản lý sẽ ngấm dần vào vốn từ vựng của bạn.
  • Thậm chí khi nó không phải là lỗi của bạn thì nó vẫn trở thành là lỗi của bạn như thường.
  • Thậm chí khi bạn tạo ra một thành công thì nhóm của bạn sẽ nhận hết phần danh tiếng.
  • Việc trở thành một chuyên gia công nghệ thì dễ hơn nhiều so với việc làm quản lý, bạn sẽ phải ném “cái tôi” của mình ra ngoài cửa sổ.
  • Bạn sẽ tập trung tạo ra những quyết định mà sẽ ảnh hưởng đến cuộc sống cá nhân của những người khác (lương, thưởng, sa thải, v.v…) và điều này đôi khi cũng khiến bạn đau cả bao tử.
  • Có thể giao công việc cho người khác, thích thú trong việc đặt ra chương trình hành động và thỉnh thoảng nói rằng, “Không. Chúng tôi không làm cái đồ chết tiệt đó.”
  • Máy tính thì có thể đoán được, nhưng con người thì rất phức tạp. Và cuối cùng thì bạn sẽ mơ mộng về việc có những nhân viên bằng robot.
  • Công việc cố vấn có thể rất đáng làm, nhưng nó cũng rất nhiều thách thức.

“Điều khó khăn nhất trong thế giới này đó là bạn biết cách làm thể nào để làm một việc và lại nhìn thấy một ai đó làm sai mà không được bình luận gì.” – Theodore H. White

Bạn đã có một con bò sữa, hãy hút sữa từ nó!

Tôi biết rằng bạn yêu thích công việc lập trình bởi vì bạn đam mê công nghệ, nhưng không một ai nói rằng bạn sẽ phải nhảy dựng ngược lên mỗi khi có một đứa trẻ ranh nào phát minh ra một cách mới để chạy những dòng byte-code. Bạn đã đầu tư rất nhiều thời gian và công sức để trở nên tinh thông công nghệ mà bạn sử dụng, và chính kinh nghiệm đó tạo ra sự khác biệt và đẳng cấp của bạn. Tiền bạc sẽ chạy theo cái gì khan hiếm, và dù một công nghệ đã cũ nhưng nếu bạn có thể thành thạo nó, thì đó chính là cách để bảo vệ khả năng kiếm tiền của bạn.

Ngành công nghệ này đang biến đổi rất nhanh, nhưng những công nghệ đã được chứng minh thì cũng cần thời gian rất lâu mới có thể thay thế. Điều đó muốn nói lên rằng bạn sẽ vẫn có khả năng kiếm mức thu nhập khá ổn trong lĩnh vực công nghệ bạn biết và yêu quý, thậm chí sau cả vài thập kỷ.

LINK: https://vinacode.net/2014/06/23/nghe-lap-trinh-40-tuoi/comment-page-1/#comment-6463

Kanban tricks for solving problems fast

 

In October, my area within Ocado Technology undertook a radical transformation. Over the course of a single day we carried out an area-wide, self-selecting restructuring exercise. The team I now work in consists of six team members. None of us had worked together before. Although most of the other new teams decided to take on a fairly traditional Scrum approach to their process, we decided that such a radical reorganisation would be a good opportunity to introduce some experimental new process ideas and ways of working. We incorporated some of our favourite Agile/Lean development techniques and spent the next three months adapting the process to fit our team. Here's a taste of some of the things we did.

We chose Kanban.

Our take on Tomas Rybing’s “arrow kanban” board.

Our take on Tomas Rybing’s “arrow kanban” board.

 

We decided to use a variation of the Arrow Kanban board, which is itself a variation on the traditional Kanban method. Where Kanban usually has "Work In Progress" (WIP) limits for each stage of the process, we simply have a "Story in Progress" (SIP) limit. While we were a new team (learning the systems and trying to get on top of in-office support) we set our SIP limit to two stories, which provided plenty of work for two pairs of developers. We're now more familiar with things, so we've given ourselves room to take on a third story, but we only do this if there isn't anything else which can be progressed or parallelised on the other stories.

Kanban is working great for us. We maintain two work queues; a "prioritised" queue and a "random" queue. Our Product Owner (PO) can move the user stories around between these queues, changing priorities whenever she likes. This means that we can be more flexible when it comes to avoiding taking on stories which we know will become blocked, we can respond to changing business needs or deadlines very easily and we can prioritise work which would otherwise cause us to block another team. We think that this is a huge benefit over sprint-based methods of working, where it's hard to estimate how much work to commit to and - even with a one-week sprint - you are left with very little room to act in an agile way when priorities change.

We decided we didn't like meetings. Well, some of them.

Most of the team were in agreement that we prefer writing code to holding endless meetings. Spending a few hours every two weeks in sprint planning sessions, estimation sessions and doing backlog grooming didn't seem like our idea of fun... and the value we thought we would get from those meetings was questionable. Maintaining a small work queue and taking on stories whenever we are ready helps us avoid these lengthy planning meetings.

As a result of Kanban and a lack of meetings, we don't estimate our stories, either. I've found that estimates are almost always wrong, even when only considered in a relative manner, so I'm skeptical that there is any value in estimating stories on a routine basis. Additionally, this removes the pressure upon the team to ensure that all of the stories estimated to be finished during a given iteration are complete by the end of the iteration – something which I’ve noticed often results in teams either speeding up or slowing down towards the end of the sprint or, worse, cutting corners such as leaving out testing in order to mark the story as “done”.

This doesn't mean we don't have meetings. We still talk about stories and break stories down into tasks, but we do this when we're about to start work on the story so that we aren't as affected by requirements changing between planning and coding. It means that we can dedicate more time to discussing complex stories, rather than bundling the conversation into a meeting with several other breakdowns also required. Very importantly, we don't require the whole team to be involved in story breakdown - just the team members who have an interest in that story. Other team members are brought up to speed during stand-ups, or when we switch pair-programming duos; something we try to do as often as possible, but perhaps not as often as we might wish to.

Removing unnecessary meetings from our calendar also meant that we have been able to spend more time doing things with more business value, such as engaging more with our users in order to keep a tighter feedback loop.

We solve problems fast.

Our team has two stand-ups a day. Yes, two. Rather than giving individual status updates, we talk through the stories we have on the board (remember - a maximum of three!). We talk about the progress made, what the blockers are and what the next steps will be. Frequent stand-ups mean that blockers can be identified and discussed more quickly, and the process has become so well-oiled that we can finish each stand-up in around five minutes.

A meme to remind us not to misuse one of our meeting codewords.

A meme to remind us not to misuse one of our meeting codewords.

 

Despite ditching sprints, we still have retrospectives. In fact, we hold them weekly. This is probably more often than most of the scrum-based teams host retrospectives. Like our stand-ups, we've made these meetings as short as possible; they're an hour. A different person hosts each week and, after discussing the things that went badly or well in the past week, we try to come out of every retro with some actionable items. If an action is specific, it goes on the board. If the action item is more culture or behaviour based, we make a meme about that aspect of our work and stick it onto our team board to remind us to take the retro discussion on-board. For example, on one occasion people disliked how our “let's take this meeting offline” codeword, “Mango”, was being used to shut people up rather than genuinely move discussion out of a meeting (see the image).

Our “three things to discuss” meeting ideas canvas fills up.

Our “three things to discuss” meeting ideas canvas fills up.

 

Sometimes, issues spring to mind which need team input but are perhaps too large to fall into the scope of a retrospective. This was most true when the team first had formed, and we wanted to make decisions about our release strategies, our code review policies, etc. To try and address these problems, we set up a section of our team whiteboard called "3 Things". People could write down things they wanted to discuss in more depth and, once three things had been written on the board, we booked in an hour-long meeting to talk about those things. Now that we've spoken about many topics, we've started to notice that decisions can be made more quickly. We're currently trialling discussing some of the smaller topics after our standups.

We measure ourselves. A lot.

Our cumulative flow diagram (CFD) shows where stories get held up.

Our cumulative flow diagram (CFD) shows where stories get held up.

 

Whenever our stories change state, we log it. From this data, we can track how much time stories spend in each state and we can measure our cycle time. I think we all agree that what we really want to be doing is writing code, rather than spending our time manually testing or working through a painful deployment process. By considering how much time we spend in each development phase, we can identify which types of stories get stuck in undesirable phases and work out how we can avoid this in future - usually by adding some more automation. We tend to look at the graphs of our data in our retrospectives so that we can look for problematic stories and follow our progress in improving the metrics we're tracking. We find that our Cumulative Flow Diagram (CFD) is particularly useful at identifying bottlenecks where stories regularly get held-up.

Histograms captured during a reto.

Histograms captured during a reto. Green blocks are the current week, orange outlines are the result from the previous week.

 

Another thing we measure in our retrospectives is our Productivity, Collaboration and Happiness. "Our" is loosely defined here - individuals tend to factor in their perceptions of how well the team is doing, and also their own view. We cast a vote (between one and five) anonymously on post-it notes for each aspect and then draw the results up on the board. Once the results are up, we compare them with the results from the previous week and discuss the reasons for any variations. People seem to enjoy this activity. Despite the voting being anonymous, I've observed that people who give one of the three aspects a low score are almost always happy to identify themselves to the group and give specific reasons as to why they voted this way. I like to think that this is a sign of excellent trust within the team.

We don't tell people how to manage their workload.

Despite the fact that I think our process is awesome (awesome enough to write a blog post), we're hesitant to tell other people how to work. A team located near us has decided to try the switch from Scrum to Kanban. I'm delighted. Although they are doing things very differently from us, we've tried to give them some advice along the way.

It's important to note that there's no silver bullet when it comes to Agile or Lean software development. Many people think that "Agile" means "Scrum", and that "Scrum" is a rigid process, but this couldn't be further from the truth. What I have realised is that if you don't enjoy your process then you probably won't enjoy following that process. Don't do something because I've said it works for my team. Don't do something because it's what all of the rest of the teams in your company do. Break the mould, and choose a process which works well for you.

I hope that this post gives you some confidence to pick and choose the parts of each Agile tool that your team finds the most useful, and ditch the parts that don’t provide enough value to your team.

Lawrence Weetman, Software Engineer

LINK: http://www.ocadotechnology.com/our-blog/articles/kanban-tricks-for-solving-problems-fast

MongoDB Admin UIs

Trang này giới thiệu rất nhiều về các tool quản trị UI cho MongoDB, tuy nhiên hiện tại mình chỉ quan tâm tới chú adminMongo.

adminMongo

adminMongo is an open source Web based administration user interface written with Node.js.

https://raw.githubusercontent.com/mrvautin/mrvautin.github.io/master/images/adminMongo/adminMongo_collectionview.png

 

adminMongo is a cross platform user interface (GUI) to handle all your MongoDB connections/databases needs. adminMongo is fully responsive and should work on a range of devices.

adminMongo connection information (including username/password) is stored unencrypted in a config file, it is not recommended to run this application on a production or public facing server without proper security considerations.

Installation

  1. Navigate to folder & install adminMongo: git clone https://github.com/mrvautin/adminMongo.git && cd adminMongo
  2. Install dependencies: npm install
  3. Start application: npm start or node app
  4. Visit http://127.0.0.1:1234 in your browser

Note: Node.js version 4.x or above is required

Electron App

adminMongo can also be used as a cross platform Electron application. Due to the size of Electron it will need to be built manually.

To build for Mac:

$ npm run-script packageOsx

To build for Windows:

$ npm run-script packageWin32

To build for Linux:

$ npm run-script packageLinux

Once built, the executable will be in the /releases folder.

Prebuilt binaries

Prebuilt binaries can be downloaded here:

Mac 64bit

Windows 32bit

Windows 64bit

The Electron builds have been tested on Mac and Windows 10. Linux has not been tested. Please report any issues.

Deploy on Heroku

Deploy

Demo (read only)

A read only demo can be seen here

Features

  • Manage from a connection level for easy access to multiple databases
  • Create/Delete databases
  • Backup/Restore databases
  • Create/Delete/Edit collection
  • Create/Delete/Edit documents
  • Create/Delete indexes
  • Query documents
  • Collection statistics
  • Export collections in JSON format
  • Server monitoring

Current limitations

  • Documents need to have an "_id" value which is a string, integer, or MongoDB ObjectId. Documents using Composite ID indexing is currently not supported.
  • Connection strings with multiple hosts for replica sets are currently not supported.

Configuration

adminMongo will listen on host: localhost and port: 1234 by default. This can be overwritten by adding a config file in /config/app.json. For example:

{
    "app": {
        "host": "10.0.0.1",
        "port": 4321,
        "password": "secureadminpassword",
        "locale": "de",
        "context": "dbApp",
        "monitoring": false
    }
}

Note: Any changes to the config file requires a restart of the application

All above parameters are usable through the environment which makes it very handy to when using adminMongo as a docker container! just run docker run -e HOST=yourchoice -e PORT=1234 ...

The config file (optional) options are:

OptionEnv-variableDefinition
hostHOSTThe IP address adminMongo will listen on
portPORTThe Port adminMongo will listen on
passwordPASSWORDAn application level password to add simply authentication
localeLOCALEThe locale is automatically set to the detected locale of Nodejs. If there is not a translation, adminMongo will default to English. This setting overrides the default/detected value
contextCONTEXTSetting a context of "dbApp" is like changing the base URL of the app and will mean the app will listen on http://10.0.0.1:4321/dbApp. Ommiting a context will mean the application will listen on root. Eg: http://10.0.0.1:4321. This setting can be useful when running adminMongo behind Nginx etc.
monitoringMONITORINGWhether to run monitoring at regular intervals. Defaults to true or on

Setting a context path

Setting a context of "dbApp" is like changing the base URL of the app and will mean the app will listen on http://10.0.0.1:4321/dbApp. Ommiting a context will mean the application will listen on root. Eg: http://10.0.0.1:4321. This setting can be useful when running adminMongo behind Nginx etc.

An example Nginx server block. Note the location /dbApp { and proxy_pass http://10.0.0.1:4321/dbApp; lines match the context set in the /config/app.json file.

server {
    listen 80;

    server_name mydomain.com www.mydomain.com;

    location /dbApp {
        proxy_pass http://10.0.0.1:4321/dbApp;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection 'upgrade';
        proxy_set_header Host $host;
        proxy_cache_bypass $http_upgrade;
    }
}

Language locale

Looking for people to translate into other languages. If you can help, grab the /locale/en.js file, translate to your language and submit a pull request.

The locale is automatically set to the detected locale of Nodejs. If there is not a translation, adminMongo will default to English. To override the detected locale a setting can be added to the app.json file. See Configuration section for a "German" example.

Authentication

By default adminMongo is not password protected. You can add password authentication by adding a password value to the /config/app.json file (See the Configuration section). Once added you will need to restart adminMongo and all routes will be protected until the correct password is added. You will then be authenticated for the life of the session (60 mins by default) or if the "Logout" link is clicked.

Usage

Create a connection

After visiting http://127.0.0.1:1234 you will be presented with a connection screen. You need to give your connection a unique name as a reference when using adminMongo and a MongoDB formatted connection string. The format of a MongoDB connection string can form: mongodb://<user>:<password>@127.0.0.1:<port>/<db> where specifying to the <db> level is optional. For more information on MongoDB connection strings, see the official MongoDB documentation.

You can supply a connection options object (see docs) with each connection.

For example:

{
    "poolSize": 10,
    "autoReconnect": false,
    "ssl": false
}

Note: The connection can be either local or remote hosted on VPS or MongoDB service such as mLab.

The connection can also be automatically initiated through the environment (or with the docker -e parameters)

Env-variableDescription
CONN_NAMEThe name of the connection to create on boot
DB_USERNAMEThe username for the database connection
DB_PASSWORDThe password for the database user
DB_HOSTThe host IP address or DNS name without the port!
DB_PORTThe port of the mongoDB database, if not provided the default 27017 will be used
DB_NAMEThe name of the database

The Connection setup screen adminMongo connections screen

Connection/Database admin

After opening your newly created connection, you are able to see all database objects associated with your connection. Here you can create/delete collections, create/delete users and see various stats for your database.

The connections/database screen adminMongo database screen

Collections

After selecting your collection from the "Database Objects" menu, you will be presented with the collections screen. Here you can see documents in pagination form, create new documents, search documents, delete, edit documents and view/add indexes to your collection.

The collections screen adminMongo collections screen

Searching/Querying documents

You can perform searches of documents using the Search documents button on the collections screen. You will need to enter the key (field name) and value. Eg: key = "_id" and value = "569ff81e0077663d78a114ce" (Only works on string "_id" fields - Use "Query Documents" for ObjectID's).

You can clear your search by clicking the Reset button on the collections screen.

Simple search documents adminMongo search documents

Complex querying of documents is done through the "Query documents" button. This allows a query Object to be passed to MongoDB to return results. Queries can be written in full BSON format or EJSON format. For example these queries should return the same results:

{ 
    ObjectId("56a97ed3f718fe9a4f599489")
}

is equivalent to:

{
    "$oid": "56a97ed3f718fe9a4f599489"
}

Query documents adminMongo search documents

Documents

Adding and editing documents is done using a JSON syntax highlighting control.

Editing a document adminMongo documents

Documents with Media embedded show previews

Documents with media adminMongo media

Server Monitoring

Functionality currently in Beta

Selected server monitoring is done at regular intervals and stored in local database store for 24hrs.

New connections require an app restart for monitoring to commence

Server monitoring adminMongo server monitoring

Indexes

Indexes can be added from the collection screen. Please see the official MongoDB documentation on adding indexes.

Viewing/Adding indexes adminMongo documents

Tests

The adminMongo API tests include:

  • Add and remove a connection
  • Add and remove a database
  • Add, remove and rename a collection
  • Create and delete a user
  • Add, query and delete a document

To run tests, simply run:

npm test

Note: You will need to ensure there is no password protection setup in the /config/app.json.

You may need to edit the variables and connection string in /tests/tests.js for your MongoDB instance.

If you see any missing tests, please submit a PR.

Contributing

  1. Fork it!
  2. Create your feature branch: git checkout -b my-new-feature
  3. Commit your changes: git commit -am 'Add some feature'
  4. Push to the branch: git push origin my-new-feature
  5. Submit a pull request :D

Future plans

Please make any suggestions.

LINK: adminMongo

LINK: https://docs.mongodb.com/ecosystem/tools/administration-interfaces/

LINK tác giả: https://markmoffat.com/

Bringing Your Web Application to Desktop Life with Electron

Sick of dealing with browser quirks? Or maybe one of your users just LOVES some old crappy version of Internet Explorer? Or do you have users that simply cannot avoid the temptation of an address bar that can take them on a journey to social media land?

This short post will show you in just a few easy steps how you can take your existing web site or application and package it up as an Electron application that they can use without ever touching a browser.

What is Electron?

Electron is a framework for building cross-platform native applications using all your favorite web technologies like CSS, HTML and Javascript. It gets all of the difficult cross-platform concerns and allows you to actually just write some code.

If you want to check it out, I'd encourage you to visit their site, however we aren't going to be spending too much time on it specifically. We are more interested in quickly using it to migrate an existing web application.

Jumping from Web to Desktop

This post is going to take advantage of the existing Electron Quick Start application that you can find on GitHub. We are going to pull it down, make a single change, and then run it to see your web application running it a semi-desktop glory.

First, pull down the electron-quick-start repository here.

You can use your favorite code editor to see what it looks like at this point :

electron-quick-start

It's pretty bare-bones, and actually it's going to stay that way. The next step is to open up the main.js file and change the contents of the mainWindow.loadURL()function from :

mainWindow.loadURL(url.format({  
    pathname: path.join(__dirname, 'index.html'),
    protocol: 'file:',
    slashes: true
}))

to :

mainWindow.loadURL('http://your-web-application-url-here')  

This will tell Electron that it needs to load the given URL when the application opens the main window. Then you would just need to run it (either directly through your editor) or via the following command :

electron .  

After running this command, Electron will do its magic and create an Electron app that points to the URL specified in your main.js file. It'll look and feel much like a browser, except that it will be sandboxed to prevent users from looking at the source or doing any other kinds of tinkering :

Blog Example

If you wanted to adjust this further, you could set your own custom icon by defining it within the icon property of your window object :

// Create the browser window.
mainWindow = new BrowserWindow({  
    width: 1024, 
    height: 768,
    icon: __dirname + '/favicon.ico'
})

As well as explicitly hiding the menu bar by calling the setMenu() function :

// Hide the menu
mainWindow.setMenu(null);  

You can see a full set of documentation here of the BrowserWindow object to configure whatever your heart desires.

Packaging things up.

So we have shown that you can easily create this Electron wrapper for your existing web site or application, but now we want to take that a step further. Let's say that you want to actually build a proper executable that would allow the user to install this "app" onto their machines.

Thankfully, the team at Electron has already handled this for you thanks to their electron-packager project, which is specifically designed to handle packaging and distribution of your application.

To get started, ensure that you have the electron and electron-packager packages installed via :

npm install electron -g  
npm install electron-packager -g  

Once the packager is ready, then another quick command will package up your application into an executable (your parameters may vary) :

electron-packager . app --platform win32 --arch x64 --out dist/  

And then you should see your new shiny executable within a new dist/appoutput directory :

Electron Directory

But What about My Sweet Scripts?

You may notice that your Javascript code might not work as expected when running inside of Electron. This is simply because Electron doesn't know about it, but you can easily change this.

Simply wrap your <script> tags as follows :

<script>if (typeof module === 'object') {window.module = module; module = undefined;}</script>  
<script src="/app/app.js"></script>  
<script>if (window.module) module = window.module;</script>  

After adding this, you should see that all of your wondrous Javascript events trigger as expected.

Getting it to folks.

So at this point, we have the application packaged up as an executable, now we have to get it to people. Once again, there's a package for that: electron-installer-windows, which will handle building a Windows installer for you and handle things like deploying updates via Squirrel.

Again, we visit the command line to get this installed :

npm install electron-installer-windows -g  

and then run it :

electron-installer-windows --src dist/app-win32-x64/ --dest dist/installers/  

One issue that I frequently encountered was an "invalid URL" error during the build process for the installer. If you run into this yourself, you can simply add a homepage to your project.json file as seen below :

"homepage": "http://rion.io",

This should resolve the error and you can go about packaging your project up as expected. The process itself will usually take a while, but afterwards you should be presented with the installer that you've come to know and love within Windows :

Installer

Now you can go distribute it out as a holiday gift to your friends, family, and loved ones.

Note: Electron actually has a specific electron-builder project that handles building installers, but I found the above one a bit easier to use. YMMV.

Just to reiterate what this is.

Firstly, let's be clear about what this is. It's a desktop application that simply wraps a given URL to your web application in a sandbox to help retain consistency and avoid any browser-specific quirks (or curious users).

Obviously Electron can do some really interesting things, but this was just to demonstrate how you could run a few commands and build an executable for your web application (or even an installer).

LINK: http://rion.io/2016/12/02/bringing-your-web-application-to-desktop-life-with-electron/

Chín thói quen xấu cần bỏ nếu muốn theo ngành CNTT

1. Không chịu đọc tài liệu trước khi dùng

Đây là một trong những thói quen tệ hại nhất nhưng lại thường gặp nhất. Có lẽ thói quen này nảy sinh từ tính thân thiện của “giao diện đồ hình” (GUI) khiến cho người dùng bồi đắp thói quen mò mẫm mà không cần đọc hướng dẫn nhưng cũng sử dụng được máy. Việc này không có gì đáng ngại đối với người dùng (rất) bình thường. Tuy nhiên, nếu bạn có ý định theo đuổi ngành CNTT một cách nghiêm túc thì hãy bỏ ngay thói quen tai hại này bởi vì đây là rào cản lớn nhất cho sự phát triển. Kiến thức vững chắc không phải… mò mà ra. Tài liệu hướng dẫn không phải vô cớ mà được viết ra.

2. Đọc lướt

Đây cũng là một thói quen tệ hại và phổ biến không kém. Ngay trên những diễn đàn, với những ý kiến và chỉ dẫn bằng tiếng Việt rất cô đọng, rành mạch và dễ hiểu nhưng vẫn có quá nhiều người chỉ đọc lướt để rồi quay lại tiếp tục thắc mắc. Đây là thói quen cực kỳ nguy hiểm bởi vì nó rèn cho trí não thói quen đọc lướt. Việc này dẫn đến chỗ kiến thức thu thập một cách hời hợt, tạm bợ và chắp vá. Nếu những ý kiến bằng tiếng Việt rất cô đọng, rành mạch và dễ hiểu nhưng vẫn không chịu khó đọc kỹ và suy gẫm thì việc tham khảo, tổng hợp các sách tiếng nước ngoài gần như là vô khả thi.

3. Bắt chước mà không suy nghĩ

Khi bắt đầu làm quen với những thứ trong ngành CNTT, cách dễ nhất là bắt chước làm theo từng bước. Nếu cứ nhắm mắt làm theo nhưng không hề suy nghĩ lý do tại sao mình làm như vậy, không thử đặt câu hỏi những gì xảy ra đằng sau những “bước” ấy thì không chóng thì chày sẽ tạo cho mình một thói quen tai hại: bắt chước không suy nghĩ không tư duy như một cỗ máy. Từ chỗ làm theo từng bước có sẵn mà không suy nghĩ đến chỗ biến thành thói quen thì khả năng nhận định và tư duy sẽ bị thui chột. Chẳng những vậy, thói quen này kiềm hãm sự thẩm thấu kiến thức xuyên qua hàng loạt những câu hỏi. Tự đặt câu hỏi chính là cách buộc trí não mình làm việc và là viên đá đầu tiên để dấn thân vào chỗ phát triển trí tụệ.

4. Sợ khó

Sợ khó tưởng chừng quá thông thường trên mọi lãnh vực nhưng trong lãnh vực CNTT thì thói quen “sợ khó” là thói quen giết chết ngay bước đầu làm quen và phát triển. Chẳng có ngành nghề thực thụ, đòi hỏi trí tuệ mà lại dễ dàng hết. Thói quen “sợ khó” biểu hiện từ chuyện đơn giản như học ngoại ngữ (để có thể tham khảo thêm tài liệu ngoại ngữ) cho đến chuyện tự mình đối diện với những khó khăn trong khi trau dồi kiến thức và kinh nghiệm. Thói quen này lâu dần ăn sâu và dẫn đến chỗ không muốn và không thể giải quyết được điều gì nếu chỉ cảm thấy có trở ngại. Nên tránh xa câu này: vạn sự khởi đầu nan, gian nan bắt đầu nản.

5. Viện cớ

Quá trình tích lũy kiến thức luôn luôn có những khó khăn và trở ngại. Nếu chính bản thân mình không tự kỷ luật và tự nghiêm khắc thì chẳng còn ai trên đời này kỷ luật và nghiêm khắc giúp mình. Từ chỗ không kỷ luật và không nghiêm khắc, chỉ cần một thời gian rất ngắn có thể dẫn đến sự đổ vỡ, sợ hãi, chán nản và để bào chữa cho sự đổ vỡ thường là những viện cớ. Viện cớ chỉ để ẩn nấp sau cái cớ nhưng sự thật sụp đổ vẫn tồn tại. Tránh xa những câu như “nhà em nghèo”, “hoàn cảnh khó khăn”, “vì em là newbie” mà nên biết rằng vô số những người khác cũng như mình và thậm chí còn khó khăn hơn mình. Nên nhớ rằng, ngay khi dùng cái cớ để viện thì lúc ấy mình đã chính thức thất bại rồi.

6. “Đi tắt đón đầu”

Trên đời này chẳng có loại tri thức đích thực nào hình thành từ “đi tắt” và “đón đầu” cả. “Mì ăn liền” có cái ngon của nó nhưng chính “mì ăn liền” không thể hình thành một bữa ăn thịnh soạn và đầy đủ. Tri thức đích thực cũng như thức ăn, nó cần điều độ, liều lượng và thời gian để… tiêu hoá. Tư duy và thói quen “đi tắt” luôn luôn dẫn đến những lổ hổng khủng khiếp trong kiến thức. Những lổ hổng ấy xem chừng không nhiều và không quan trọng khi kiến thức còn ít ỏi và nhu cầu công việc còn sơ khai. Tuy nhiên, một khi đối diện với những khó khăn và phức tạp trong công việc và trong đời sống thì những thứ “đi tắt đón đầu” là nguyên nhân sâu xa của những đổ vỡ và thất bại. Hãy nhớ: đừng đi tắt và đừng đón đầu bởi vì chẳng có cái đường tắt nào trong hành trình đi tìm tri thức.

7. “Nghe nói là…”

Cụm “nghe nói là…” là một cụm phổ biến đến độ chóng mặt. Bất cứ một ngành khoa học hay có liên quan đến khoa học không thể dựa trên “nghe nói” mà luôn luôn cần dựa trên các bằng chứng khoa học và những bằng chứng ấy cần chính xác và cụ thể. Chính vì có thói quen “nghe nói” mà đánh rớt những cơ hội tìm tòi và kiểm chứng; những cơ hội quý báu để trau dồi kiến thức và kinh nghiệm. Cái gì không rõ thì nên tìm tòi và đừng “nghe nói” mà phải được thấy, được phân tích và được kiểm chứng. Không bỏ được thói quen này thì cách tốt nhất đừng bén mảng gần bất cứ ngành khoa học nào vì chỉ chuốc lấy sự thất bại và lãng phí.

8. Niềm tin và hy vọng

Trong khoa học, khi nói đến kết quả và sự kiến tạo hoặc thậm chí con đường đi đến sự kiến tạo và kết quả thì hoàn toàn không có chỗ cho “niềm tin” và “hy vọng” một cách mù mờ. Thói quen “restart” lại máy hay “restart” lại chương trình với “hy vọng” nó sẽ khắc phục sự cố đã trở thành thói quen cố hữu. Nếu không có điều kiện thay đổi nào khác thì có “restart” một triệu lần và hy vọng một triệu lần thì kết quả vẫn y hệt nhau. Đừng “tin” và đừng “hy vọng” vào sự thay đổi của kết quả nếu như chính bạn không kiểm soát và thay đổi để tạo thay đổi trong kết quả. Tất cả mọi hoạt động từ lập trình cho đến quản lý hệ thống, quản lý mạng, bảo mật, reverse engineering…. thậm chí đối với người dùng bình thường, khi kết quả không như ý, sự điều chỉnh là điều cần thiết thay vì lặp lại y hệt hành động và chỉ… hy vọng.

9. Không vì trí tuệ mà vì… “đẳng cấp”

Lắm bạn lao vào ngành này không phải là vì trí tuệ, vì kiến thức, vì đóng góp một cái gì đó ích lợi cho xã hội mà là vì… đẳng cấp mơ hồ nào đó. Nếu tiếp tục lao vào và chọn lấy một muc tiêu mơ hồ thì sẽ không bao giờ đi đến đích được. “Đẳng cấp” là một thứ mơ hồ, vô ích và đầy cá nhân tính nhưng khi nó biến thành thói quen và mục tiêu để nhắm tới thì nó chẳng mang lại được gì ngoài sự thất bại ngay từ đầu vì hoàn toàn không có một phương hướng nào cả. Trau dồi kiến thức hoàn toàn khác với việc xoa dịu mặc cảm (“đẳng cấp”).

LINK: http://tapchilaptrinh.vn/2014/12/22/chin-thoi-quen-xau-can-bo-neu-muon-theo-nganh-cntt/